Re: ... and how camel should be

Jeffrey Stedfast <[email protected]>
Newsgroups gmane.comp.gnome.evolution.devel
Organization Novell, Inc.
Message-ID <[email protected]>
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.
[email protected]  - www.novell.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.