Correction in-line... David Collier-Brown wrote: > Elad Lahav <[EMAIL PROTECTED]> asjed > | I'm looking into the performance of a simple, single-threaded, TCP > server on a T1000. > | According to mpstat, the strand running the server is about 50% idle. > However, performance > | counters suggest that it is executing about 230 million instructions > per second, which, > | from my experience thus far, is pretty much the limit of a > single-threaded application. > | Roughly the same numbers are reported for the strand handling the > interrupts (the two are > | on different cores, so there is no competition for shared resources). > The NIC is reading > | at 700Mbps, so the network is not the bottleneck. > > | I'm having a hard time putting all of this information together, as > there is no clear > | bottleneck. Also, I think there is a more general issue here: how can > one interpret > | per-strand mpstat numbers, as the resources available to a strand > change dynamically with > | the load on a core? > > The bottleneck is arguably code path length, as you're seeing almost > exactly one thread's worth of CPU. > > The way to measure performance of an app which uses TCP is to write > a script that uses snoop output or wireshark "save as CSV" data, and > count request-response pairs per second (TPS, in the computer science > sense of the term), and get the latency,total response time, transfer > time ant BPS throughput by doing this calculation: > > request time -> t0 > first response -> t1 (I had written t2 originally, in error) > last response -> t2 > > and then compute: > latency = t1 - t0 > transfer time = t2 - t1 > total response time (R) = latency + transfer time > bytes/second = bytes / transfer time think time = t2 from previous > transaction - t0 > > You should see response time R grow slowly until something saturates, > when it will head upwards like the handle of a > hockey stick. > Then report R versus TPS as a graph, This is traditionally > called the hockey-stick curve. That will tell you when to > add more instances of the program or buy more machines (;-)) > > Feel free to email me directly. > > -- dave (who went to UW as an undergrad) c-b
-- David Collier-Brown | Always do right. This will gratify Sun Microsystems, Toronto | some people and astonish the rest [EMAIL PROTECTED] | -- Mark Twain cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191# _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
