Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: [proposal] apr_thread_setconcurrency()
From: Ian Holsman <ianh@cnet.com>
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
Cc: Aaron Bannert <aaron@clove.org>, dev@apr.apache.org
In-Reply-To: <20010916201325.Y12417@ebuilt.com>
References: <20010914154448.V11014@clove.org>
	<20010914154959.I12417@ebuilt.com> <20010914162151.Z11014@clove.org>
	<20010914183347.K12417@ebuilt.com> <20010915164339.H11014@clove.org>
	<20010916005510.L12417@ebuilt.com> <20010916195919.P11014@clove.org>
	<20010916201325.Y12417@ebuilt.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 17 Sep 2001 09:13:56 -0700
Message-Id: <1000743236.5011.6.camel@griffon.cnet.com>
Mime-Version: 1.0

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


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