Danny,

> Peter, I've got two sets of results, one from James before I applied
your
> patch, the other after it all other factors remian the same, thats the
> only comparison I'm making.
> 
> in previous tests I consistently ran 10,000 1k mails through the
spooler
> at slightly over 14 mails per second. (using a single connection per
100
> mails)

Ok.

I understand your comparison.  And that's one of the reasons I asked
what your thread pool maximum was.  Because I've got a different set of
results, and you clearly didn't grab all the changes at once (witness
the assembly.xml change).  So I'm asking you to confirm that you've got
a valid thread pool maximum.  Obviously the Watchdog approach needs more
threads that the other system - it was designed that way and the
configuration modified.  If it's still at the earlier default of 40,
then the Watchdog method won't allow 20 connections.  Period.

--Peter

> 
> d.
> 
> > -----Original Message-----
> > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
> > Sent: 13 October 2002 19:37
> > To: 'James Developers List'
> > Subject: RE: Peters patch doesn't actually work...
> >
> >
> >
> > Danny,
> >
> > > sorry, thats the wrong way round its assmebly.xml that needs
twiddled.
> > >
> > > However, applying the same SMTP test, this time 2000 1k mails from
20
> > > threads, Peter's changes resulted in more refused connections, 1st
> > after
> > > only 16 connections have been attempted and with no more at all
after
> > 361
> > > mails have been delivered.
> > >
> > > I haven't looked at the code really, but my empirical view is that
> > SMTP
> > > suffers from these changes.
> >
> > I've been running these tests all night with a slightly tweaked
version
> > of the patch I submitted (there was an erroneous notify() call in
that
> > patch).  It runs fine under load, although there do seem to be some
> > problems with the spooler if its put under consistent load.  It's
not
> > clear what the relationship is to the handler changes.  We've never
> > driven the spooler under serious load, so we have no idea what load
it
> > can take.  I'm looking into this.
> >
> > Might I suggest that you check your configuration.  My first guess
would
> > be that you didn't correctly bump up the maximum number of threads
in
> > your server's thread pool.  The specified number of 40 would be too
low
> > for your test, since 20 connections would consume 40 threads alone,
not
> > to mention that all the other blocks use at least one thread apiece.
> >
> > --Peter
> >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:james-dev-
> [EMAIL PROTECTED]>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:james-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:james-dev-
> [EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to