thanks philippe now the executive summary: does it mean that zinc is well positioned compared to others?
Stef On Dec 18, 2010, at 11:30 AM, Philippe Marschall wrote: > 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 > > > > >
