[Ur] TechEmpower Benchmarks

[Adam Chlipala]

On 11/27/2013 11:35 AM, escalier at riseup.net wrote:
>> I expect it will immediately reduce dramatically the number of "errors" reported in the benchmark results.
>>
>> I rebuilt the benchmark with the HEAD version of Ur/Web. Unfortunately, it
>> doesn't seem to have done much for the socket errors.
>>      

OK, so I was overly optimistic. :)  The change I made did fix some 
errors that I had reproduced with the Siege benchmarking tool, but wrk 
was doing something different.  After some experimenting with wrk, I 
think I have the problem solved now, in the public Ur/Web repo.

> > ur/web doesn't have keep-alive
>
> Is that right? 

Well, the question may be misleadingly imprecise, but the Ur/Web 'http' 
protocol doesn't have any implementation of keep-alive.  My "fix" is in 
two parts:
1) Add "Connection: close" header to indicate that the connection isn't 
so alive after all.
2) Add "Content-length" header, which seems important for clients that 
may expect the keep-alive style.

I've followed a lazy approach in adding features to the tiny HTTP 
servers that 'urweb' will generate.  They were never intended to be 
serving production web requests directly, but I hope the small changes 
I've made are enough to allow using them with wrk.

> When I set max_pred_locks_per_transaction to 256 in my local
> postgresql.conf (from the default of 64), those errors seem to go away.
> I've opened an issue for that
> (https://github.com/TechEmpower/FrameworkBenchmarks/issues/632).
>    

Thank!  One other change I've just pushed is inspired by the last few 
error messages in the Postgres-related log you showed us.  These look 
suspiciously like optimistic concurrency faults, which should be handled 
by retrying transactions (as the HINTs suggest).  I had already 
implemented checks for a few codes that I know signify such a state, but 
I may be missing one; so I added printing of the error code in the log 
messages.  This means I should be able to use future logs of this kind 
to figure out which cases should be added to the Ur/Web Postgres code.

I'll be curious to hear whether, after the latest changes, everything 
works well locally for you, escalier.  (The most likely failure would be 
the same optimistic-concurrency faults, I think.)

Do we know if there will be any more practice runs of this benchmarks 
round?  Since the Ur/Web code seems basically to have served 0 requests 
in the first run, it would be good to get some confirmation that things 
are hooked up properly!