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 [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 364-8608
