Re: [Evolution-hackers] ... and how camel should be

[Jeffrey Stedfast <fejj novell com>]

On Tue, 2006-02-14 at 00:56 +0100, Philip Van Hoof wrote:
> On Mon, 2006-02-13 at 17:05 -0500, Dave Richards wrote:
> > I added this comment to the bugzilla report.  I'm not a developer, but
> > I do have to *deploy* Evolution to hundreds of people.
> > 
> > 
> > --------------------(snip)-------------------------------------------------------------------------------------------------------------
> > I have been watching this thread on evolution-hackers.  Please
> > remember when considering design of these things, that some of us are
> > running multi-user systems with hundreds of users on at a time.  There
> > might be cases where memory is better than disks in such cases.  I
> > have hundreds of users and can easily get all of this into 16GB.  What
> > will be the result of all of those people now using the disk?
> 
> Why wont it slowdown your evolution instances? Simple:
> 
> Your users typically don't need every single message header that can be
> viewed using the summary view at every millisecond of the day. They
> typically need 50 of them per second, perhaps 100 or 200 for insanely
> extreme cases.
> 
> Their fingers can't scroll fast enough for a disk (that is largely
> cached) to be to slow. Also note that the index which must be iterated
> on that disk will be a continuous block of data. Such data can be read
> almost instantly (how long does it take to read a few megabytes from a
> modern disk? --> that would be the entire index, you only need lets say
> 100kb of that data per ten seconds IF the user is really fast).
> 
> If the users start to scroll lots of times through their summary view,
> the Linux kernel will probably put some of these indexes in memory
> buffers.
> 
> Imagine spastic users that do nothing but scroll all day long at
> extremely rapid speeds .. multiply that with 10.000 such users, and you
> still wouldn't have any problems at all.

Even for single-user, disk-summary-branch was slower than the current
in-memory implementation.

Now scale this to many hundred users all accessing the same disk and you
will notice a much larger impact on performance because there will be a
lot more disk seeks compared to just single-user.

-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com