On 11/27/2013 11:35 AM, [email protected] 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!
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
