On 18.12.2010 09:17, Stéphane Ducasse wrote: > Hi philippe > > thanks for helping sven. Now for the blind like me. What do the tool says? > Because not too shabby is difficult to fully interpret :)
Benchmarks always are ;-) Management summary it does: ~30 Mbytes/sec (bytes not bits) and 1778 requests per second. Now comes a long section why this is unrealistic and you can't expect this performance in the real world. You can look at the benchmark as an upper bound of what the server is capable of. It makes 10000 requests using 10 concurrent, recycled connections to the local machine. On the Smalltalk side there's a simple Seaside request handler that takes a 16k byte array (the www.seaside.st homepage) and writes it to the response. Note that a smaller page would obviously result in more requests per second and less throughput while you would expect to see the opposite from a bigger page. There are no sessions, continuations, rendering or encoding involved because the idea is to stress the sever, not Seaside. On the other hand conversion to and from Seaside requests and responses happens as well as the whole context and handler chain are set up. In a real world scenario you would spend much more time in Seaside and the back end of your application¹. The connections would be slower, each connection would not make that may requests and you'd have network latency. To get an idea what impact latency can have see [1]. Other points to note: - The server does not lose any requests. This is a problem I've run into using the same benchmark on other Smalltalk servers. - Most requests come back fairly quickly, 80% in 1 ms. The longest takes 155ms (maybe GC interference). One important point this benchmark does not cover is how well does it clean up hanging or stale connections. This is a much bigger issue in production than a few Mbytes/sec. To reproduce load the package AJP-Benchmark from [2], register AJPFastRequestHandler (see class side), hit the page once with you browser so that the cache gets initialized and run: ab -k -c 10 -n 10000 http://127.0.0.1:8080/fast (ab comes with every Mac) There are other request handlers in there that do encoding and rendering which obviously results in worse performance but more realistic numbers. They are designed to stress Seaside rather than the server. [1] http://blogs.webtide.com/gregw/entry/lies_damned_lies_and_benchmarks [2] http://www.squeaksource.com/ajp ¹ you could use a caching filter though that does a lookup in a dictionary Cheers Philippe
