On Fri, 2001-08-24 at 17:40, Justin Erenkrantz wrote: > On Fri, Aug 24, 2001 at 05:21:11PM -0700, Marc Slemko wrote: > > On Fri, 24 Aug 2001, Justin Erenkrantz wrote: > > instead of looking at raw network thoughput look at heavy users of pools, CPU utilization, and truss/prof output. and compare these results with standard pool, and with brians patch.
I would concentrate more on getting 100 rps going through in the following conditions: * standard file no parsing (ie .. sendfile) * mod include with 2 includes (header/footer) (as this REALLY uses pools heavily) * Keep-alives I'll fire up the 8-way box on monday and compare sanders and brians pool code against the 'stock' pool and see what I can see. There was also the pool replay code I wrote a while back which could be used to compare pool allocaters, as well as dreieds memory tests for the SMS. BTW can flood simulate a steady # of requests being attempted per second? or does it just fire up N threads/processes and whack away. ( check out http://www.cs.rice.edu/CS/Systems/Web-measurement/ for more info) > > > If you have the backplane (my guess would be Gigabit Ethernet) to > > > > Well, or just a less powerful server. The goal isn't the best raw > > numbers, the goal is comparison. Granted, that comparison can be > > different on various sized machines (eg. SMP vs. not, etc.). > > Well, part of the problem is that Sander's pool optimization is > intended to benefit MP boxes. It adds thread-local free-lists - so > the benefit is probably only noticable on MP boxes under load. > > The problem is that I can't get enough out of our network (with > the URLs I hit) to see if it improves the performance. I will > try to adjust the URLs I hit to see if I can move the bottleneck > back to the CPU. > > Any suggestions here? -- justin -- Ian Holsman Performance Measurement & Analysis CNET Networks - 415 364-8608
