On Thu, 31 May 2012 09:57:38 +0200 Juan Jose Garcia-Ripoll <[email protected]> wrote:
> You do not, by any chance, have the commit ID which last proved stable for > you. It would help me list the changes that might have had an impact. I checked my logs and I believe that it might have been fbd3587b1af74a2c5efcdb70671ec9314802fd2e that I merged with then. That's slightly far back, but it's plausible, as I then ran the HTTPd for 30 or so days, after which I reported here the uptime on May 16. So I did another short test run using -c16 -n1000 and even with 1000, if I do several runs one after the other rather quickly, some runs take a lot longer to finish than others. Example: Requests per second: 2816.90 [#/sec] (mean) Requests per second: 1046.03 [#/sec] (mean) Requests per second: 76.03 [#/sec] (mean) Requests per second: 252.84 [#/sec] (mean) Requests per second: 2564.10 [#/sec] (mean) Yet I remember using successfully up to -n10000 on that instance that I let run 30 days, with good constant performance. Also, in the slow cases such as the 76.03 above, the threads seem to be in CPU-busy loops. However, if I check the WCHAN of the various threads in top(1), I see those threads alternate between CPU/RUN/pause. If I use ktruss(1) on the process, I see a lot of sched_yield() calls. I should probably try to revert to that older merge and try again, to really confirm that I don't experience that issue with it. I'll try to do this later on today. Thanks, -- Matt ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ecls-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ecls-list
