-----Original Message----- From: Alexander Staubo [mailto:alex@mop.no] Sent: Thursday, June 17, 1999 11:38 AM To: Zope Mailing List (E-mail) Subject: RE: [Zope] Zope performance too low ?
I'm not familiar enough to Linux to say this for sure, but my guess is that it _would_ be using a high-resolution system timer.
Nope, 'ab' uses gettimeofday(2) to return microseconds, and then does an internal divide by 1000 to return milliseconds. This is done all with itegers however, I suspect there is a loss of precision.
Ouch. These extremely low transfer rates bother me. The theoretical bandwidth on a local machine transfer should be way, way higher. Otoh, your document was very small, so the stop/start, connect/teardown margins would be relatively high. I'd like to see benchmarks with longer (>3KB) documents.
I redid the same benchmark between two linux boxes on my desk (the same server as before, the client is RedHat 6.0 on a P166 w/ 10Mb Ethernet card) with a 36K document, and got 656 KB/sec (~36 requests/sec 147ms average response time), the effective limit on a moderately loaded 10Mb/s Ethernet lan. So, Zope can at least hose a 10 Mb Ethernet (Note, a 70MB FTP between the two machines yielded 800 KB/s, I think the amount of request/response and tcp connect/disconnect overhead could account for the other 144 KB/s, at least to a 10% margin of error). When Rob buys me a 100MB card for my other machine, I'll rerun the benchmark to see if Zope can beat the 10Mb limit. Also not that the ~37 requests per second I got (this is the average between all benchmarks) equates to approx *3.2 million hits per day* on one moderately fast PII with no fancy hardware.
Otoh, if transfers really were fast (that is, faster than 10-11KB/sec), and the time taken to complete a request was low, the transfer time should explode exponentially. (Eg., 10K transferred in 10ms should yield a transfer rate 1MB/sec.)
With abitrary precision numbers, yes. I don't have enough time to investigate why the number was so low for my initial benchmark.
I'd be very interested to hear about what the CPU load was during the test run. If it's anything above 5-8% (average), that's not promising at all. The fact that adding more concurrent sessions did not regrade performance seems to indicate that CPU load was not too bad.
Note that load average and % of time spent in the CPU are not the same thing. The load average hit 1.5 but that just means the machine was busy, not swamped. To test a a vague theory here, I fired up X, Netscape, vmware (which is a massive CPU hog) and a bunch of shells and XEmacs, and ran a 10000 request benchmark. The machine ran smoothly, vmware didn't stutter or pause, X switched quickly between virtual screens, and XEmacs didn't even appear to feel it. Meanwhile Zope happily pushed 538 Kb/s out the ether card.
I'm planning on putting together a simple httplib-built benchmark test just to get some raw numbers, although I'd like to try putting the timing logic inside Zope.
We would be interested in seeing what you come up with (code and numbers). -Michel