[Ur] TechEmpower Benchmarks

[Vladimir Shabanov]

How many threads you've set to handle requests (-t option)? By default
Ur/Web only runs two threads which I think is not enough.
In my project I'm using -t 32.

When I've benchmarked Ur/Web long time ago I've also seen a connection
errors. But it was solved by upgrading frontend from nginx 0.7.x to 1.x
(something with keep-alive connections and maybe the way it works with
backend). Can't say what will happen on direct benchmark w/o frontend
webserver (ur/web doesn't have keep-alive and benchmarking tools may not
manage connections as effective as nginx).

In my tests Ur/Web was able to sustain 1krps with 1000 concurrent
connections and with several requests to postgres in each request.


2013/11/27 <escalier at riseup.net>

> > 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.
>
> `./wrk -d 5 -c 10 -t 10 'http://127.0.0.1:8080/json'`
>
> Running 5s test @ http://127.0.0.1:8080/json
>   10 threads and 10 connections
>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>     Latency     1.32ms    0.90ms   3.60ms   85.64%
>     Req/Sec     0.90k   391.67     1.44k    79.53%
>   44289 requests in 6.00s, 7.98MB read
>   Socket errors: connect 0, read 44281, write 0, timeout 2
> Requests/sec:   7386.89
> Transfer/sec:      1.33MB
>
> > escalier, do you know if there's a way to request a higher value of the
> configuration setting mentioned in the hint?
>
> 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).
>
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20131127/dd441ef2/attachment.html>