[Ur] TechEmpower Benchmarks

[Adam Chlipala]

On 12/12/2013 06:44 PM, Vladimir Shabanov wrote:
> Although I wouldn't use urweb HTTP for direct requests serving. There 
> are many other things that nginx do and urweb doesn't (and shouldn't). 
> Static files serving, HTTP compression, SSL, GeoIP.
>
> And the most common thing proxies are useful is for handling slow 
> connections. Ur/Web processes request, sends it to proxy and it's free 
> (db transaction finished, socket/thread freed). The proxy then can 
> send response as long as needed.

That makes a lot of sense.  I don't know if the connections in this 
benchmark are slow enough to make such issues prominent, since they're 
just within a single data center.

I wouldn't be surprised if here each TCP send() call succeeds 
immediately, consuming the whole buffer, so that the kernel is in effect 
doing the kind of buffering you suggest.  It would be nice to get some 
empirical sense of it.

> Fix me if I wrong. But Ur/web uses fixed number of threads to handle 
> requests. So if all threads are busy request handling is stalled. So 
> just a few clients with bad connection can stall all the app.

Definitely true.  It seems worth trying with a proxy across a connection 
with comparable performance to what the benchmarking uses (gigabit 
Ethernet).

Anyone want to set up such an experiment with Nginx or another system?

> I also think that there are many nasty HTTP protocol hacks. Buffer 
> overruns and so on. Nginx is tested to work with most of them, Ur/Web 
> doesn't. So I think direct serving of requests w/o proxy should be 
> used only for benchmarks.

I've certainly tried to write the Ur/Web HTTP code to avoid C undefined 
behavior, but of course it couldn't hurt to use C code that has seen a 
lot more use and concerted bug-finding.

One security issue that I'm very happy to let a proxy handle is 
timeouts.  As an extreme case of what you mention above, an Ur/Web HTTP 
process now is trivially DoS'd by opening many connections that sit idle 
forever.

This benchmark, though, calls for choosing performance over security, 
I'd say, in boring aspects of deployment that are orthogonal to Ur/Web 
the language.