<h1>Hello TWUG!</h1>
. His point is that things like Twitter are difficult to scale across several machines. The slowness of dynamic pages, he claims, is tried to be made up by advanced caching strategies. He goes on to check how fast certain languages are at serving dynamic content. He gets these numbers:
Clearly, his machine is faster than mine, because serving the same file statically, my Apache (single-threaded using httpd -X) can do only 1850 requests per second, that is 0.5 ms per request. (I use this benchmark:
httperf --hog --num-conn 10000 --uri http://localhost:9090/?name=Niko
). Here are the numbers I get:Anyway, I find interesting to mention that Comanche is not far from Apache. Comanche can serve the same page dynamically (the name is a GET parameter) in 1.1 ms, for which Apache takes statically 0.5 ms. As for Apache-php vs. Comanche, I'd call it a tie.
The Squeak code for the Http server would be this:
ma := ModuleAssembly core.
ma addPlug: [:request | HttpResponse fromString:
(String streamContents: [:s|
s nextPutAll:'<h1>Hello! ';
nextPutAll:( request fields at: 'name');
nextPutAll: '</h1>']).].
(HttpService startOn: 9090 named: 'Example') module: ma rootModule
By this way, as the above snippet suggests, a standard Seaside installation for Squeak is quite able to make RESTful applications. Just avoid the Seaside framework and plug right into the Comanche web server.
For completeness, the PHP-code:
<h1>Hello <?=$_REQUEST['name']?></h1>
Update
By the way, this seems to be about 10 % faster:
s:=(HttpService on: 8080 named: 'Example Http Service').
s onRequestDo: [ :request |
HttpResponse fromString:
(String streamContents: [:s| s nextPutAll:'<h1>Hello! ';
nextPutAll:( request fields at: 'name');
nextPutAll: '</h1>']) ].
s start
John Fremlin wrote me that I should test against lighthttpd.
ReplyDeleteNico, would you make the same benchmark comparing Commanche with Swazoo as well?
ReplyDeleteHmm, ApacheBench just won't work with osx. http://stackoverflow.com/questions/932595/apachebench-aborts-with-a-strange-error-message
ReplyDelete