I've just pushed an Ur/Web change that I hope will have a large effect
on the benchmark results.
Previously, when a standalone Ur/Web HTTP server was run in keepalive
mode, it would assign connections one-to-one to threads, as threads
become available after finishing with previous connections. If a client
sent just one request at a time, threads would waste a lot of time
blocking, waiting for new input, even when other unassigned connections
had full HTTP requests available to parse.
Because of text in the benchmark description about "HTTP pipelining," I
had assumed that clients would be sending nice long streams of many
requests, without waiting for responses first. For all I know, the
benchmarking program really does behave like that, but network latency
is high enough that requests on a connection appear rather spaced out in
time. In any case, it turned out to be useful to make threads switch to
different connections when their current connections have no pending
requests.
Testing with localhost connections, throughput improved by 5X.
Connecting to my local machine over the Internet from a slow VM,
throughput improved by 3X. I'm hoping that the VM isn't too slow to
make the results interesting, so that I can sort of think of the real
benchmark situation, with gigabit Ethernet connecting machines, as some
interpolation between these figures. :)
On 12/25/2013 04:04 PM, Adam Chlipala wrote:
Here are some more thoughts on this benchmark competition:
http://www.techempower.com/benchmarks/
which has been discussed here a bit already.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
