One million benchmark propagandas per second! Your way out with Play framework.
It is certainly amusing to throw lots of requests at different servers, collect numbers, arrange them in grids and ... blog about it! It is especially easy and not time consuming. Does it solve a problem, not so sure. It is particularly ignorant to most performance challenges: what are you benchmarking in your "hello world" app? How fast a framework is at writing a sequence of characters to a socket? What happens if you have a complex database query, a long computation, or an IO call taking some time? When you have a bottleneck in your app that will only allow you dozens of requests per seconds, what do you do with other thousands of requests? the worst will be keeping them in waiting forever consuming uselessly resources like sockets and memory. Same thing applies to messages, what happens if a particular user can't receive as many messages per seconds as your app is trying to push? there is no one answer, some time buffering is good, dropping old or new messages can be a choice or even sometimes closing that particular socket.
There is no obvious solution to these problem and the best is to start with understanding your App, its bottleneck, isolate some parts and design your own app failure. And to do that, Play web framework gives you the necessary low level signals with a higher level concepts and API allowing you to take necessary decisions to optimize your app.
Sadek Drobi (@sadache) is the CTO of Zenexity and co-creator of the Play Framework.