On 3 Jul 2006, at 11:35, John Buckman wrote:
No, but on the other hand, most interactive web sites have response
times over 3 seconds. Amazon, for instance, now is frequently >10
seconds for a book page load. Yahoo, with it's page times
consistently under 1 second, is a pleasure to use.
Yeah, that is ridiculous. I think with Amazon a fair bit of time is
also lost rendering the horrific HTML and Javascript they use, so the
page actually generates faster than you see it. Just nice and clean
(X)HTML with a good CSS style sheet is the way to go.
questions you will hear is "how do you scale". Engineering for
scalability way beyond your current needs really will help sell
your business (I've sold two web-based businesses, and have been
through discussion this quite a few times)
Yup! I wouldn't mind sativo.co.uk to be sold at some point, so that
was very important. As was internationalization; it can speak as many
langauges as you want and run unlimited amounts of country and/or
white-label sites.
Too many "newbies" also mix their HTML and code way to much. I know
my "profile" page is a relative biggie; about 5 different tables are
queried to build it up. Because I program everything in API style,
there is one procedure that gets the profile based on the ID and
returns an ns_set with all the data. This then gets passed to the
procedure that generates the HTML. So there is nothing stopping me
from caching a serialized version of this ns_set in a BDB and using
that. The "profile.adp" page wouldn't change, nor would the HTML
procedure. Just develop the cached "getter" and swap it out...
There's a C client-side module for Lucene, which I assume could be
fairly easily integrated into a Tcl module. However, I believe the
server-side is Java, which many are biased against.
I am not biassed against Java, just against lazy-assed EJB abusers
that think having a "pluggable storage back-end" is more important
than knowing how to use a database... ;-)
There really is not much reason for a Java-based database (full-text,
relational, b-tree or any other) to be significantly slower than a
proper OO C++ based one. Highly efficient C code is another matter,
though.
One of my colleagues is now using Lucene to index a massively growing
corporate instant messaging (with word, etc attachments, thank you)
and is having great results with gigabyte indexes on an overworked,
shared, development box. It's probably one of the few technically
sound Apache/Jakarta projects! :D
scenario. Typically, people use fancy load-balancing machines that
send the same user to the same machine every time, which is more
complicated that I like.
Yeah, plus it takes away fail-over. If you have 1000 customers
hitting one server and it falls over, that is 1000 customers annoyed
their shopping cart just emptied out...
In such a situation I would opt for a pair of machines that do
nothing more than store the sessions and replicate them; all in BDB.
Front-end web servers get a session ID and just retrieve it from
these back-end caches.
DJ Bernstein (of qmail fame) wrote a read-only database library
that's insanely fast, about 3x faster than bdb in my own tests,
which could be useful in certain scenarios.
It's probably the perfect back-end for a search engine that gets
periodic updates, like Google, where on big index is created off-line
and then stored on all the machines come roll-out time. (of course
theirs is chopped into pieces and multiple machines each get a
different chunk)
I am definitely going to have a play with ns_berkelydb soon, I should
know more about it! Also eagerly awaiting nsdci!
Cheers,
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
