Re: svn commit: r437423 - /spamassassin/branches/tvd-multi-mass-check/masses/mass-check

[Theo Van Dinter <fe...@apache.org>]

On Sun, Aug 27, 2006 at 06:01:04PM -0400, Theo Van Dinter wrote:
> On Sun, Aug 27, 2006 at 10:45:38PM +0100, Justin Mason wrote:
> > hey dude -- looks very cool.  How many machines have you tried it on
> > so far?
> 
> :)  None, yet.
[...]

Ok, the code is generally usable at this point -- I can run the server,
plus clients on both machines that I have, and the results all come
out the same.  I need to still clean up the mass-check code a bit and
document some more, but I think it's beta-ish at the moment. :)

Some preliminary results with a small set of ~4900 messages:

Original version (trunk w/ -j2):			7:42  (5.3/cpu/sec)
New version in normal mode (no client/server w/ -j2):	7:33  (5.4/cpu/sec)
Client/Server w/ just remote client w/ -j2:		10:08 (4.0/cpu/sec)
Client/Server w/ local and remote clients w/ -j2:	5:08  (8.0/cpu/sec)

I should be able to tweak up the remote speed some more -- this was w/
the defaults of max 1000 messages per run.  Having a small dataset, and a
limited number of messages per run causes the overhead to be a larger
percentage of time than it would be w/ more messages and more messages per
run.


BTW: We should figure out why the throughput is so crappy now though.
As I recall, I was able to push through 10-12 msgs/cpu/sec on earlier
versions of SA.

-- 
Randomly Generated Tagline:
"... the menu is written in more elementary Spanish than a Dora the
 Explorer episode ..."
         - Karl Chalabala about a lunch menu at work

Re: svn commit: r437423 - /spamassassin/branches/tvd-multi-mass-check/masses/mass-check

[Theo Van Dinter <fe...@apache.org>]

On Fri, Sep 01, 2006 at 12:01:42AM -0400, Theo Van Dinter wrote:
> Some preliminary results with a small set of ~4900 messages:
> 
> Original version (trunk w/ -j2):			7:42  (5.3/cpu/sec)
> New version in normal mode (no client/server w/ -j2):	7:33  (5.4/cpu/sec)
> Client/Server w/ just remote client w/ -j2:		10:08 (4.0/cpu/sec)
> Client/Server w/ local and remote clients w/ -j2:	5:08  (8.0/cpu/sec)

It occurred to me last night after sending this that the last msgs/cpu/sec
number isn't correct: instead of 8.0 it should be 4.0 since there were
double the number of CPUs from the other three runs.

So in short, while our throughput per cpu goes down due to overhead, we have
more CPUs, so in the end we get faster overall throughput.

-- 
Randomly Generated Tagline:
"Sleeping is the highest regard of genius."      - Kierkegard