apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: [proposal] apr_thread_setconcurrency()
Date Mon, 17 Sep 2001 16:13:56 GMT
On Sun, 2001-09-16 at 20:13, Justin Erenkrantz wrote:
> On Sun, Sep 16, 2001 at 07:59:19PM -0700, Aaron Bannert wrote:
> > I don't think it's a quirk of the thread library, I think it's
> > fully expected. For the sake of others, here's an excerpt from the
> > Solaris 8 pthread_setconcurrency(3THR) man page:
> In testlockperf, you are assuming that all of the threads have 
> started and will compete for the locks.  In a M:N implementation, 
> this assumption is false.  You end up executing in serial rather
> than in parallel.  This only occurs because you never hit a
> user-scheduler entry point in testlockperf.  In the case of a MPM,
> you will be hitting them left and right.  =-)
> Therefore, you need to devise a strategy within testlockperf to 
> ensure that all of the threads are ready to compete before 
> continuing the test.  The suggested sleep is one way - condition
> variables *may* be possible, but it isn't completely obvious to
> me how that would work.  -- justin
> P.S. If you are running a site where you get 50,000 hits a minute,
> you shouldn't have MRPC at 10,000.  I'd be curious to see what
> cnet runs with.

on our heaviest day (the bombing) we we're getting ~7,500 HTML pages 
a minute. assuming ~6 images per page we got ~50,000 hits a minute.
(on a single machine)
this wasn't a normal day, we don't normally do THAT much traffic.
we currently have Max Requests Per Child set at '512' on our 1.3 
servers, mainly due to memory leaks.


Ian Holsman          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608

View raw message