RejectedSoftware Forums

Sign up

Vibe Benchmark Results

Related to the error I posted, I ran some benchmarks with apache-bench to see how it compared to a similar service running on Tomcat using Jersey. Below are the results, though it's not an even comparison as I couldn't get 100K requests to work due to the error I found:

Vibe (100 users, 100 requests)

Concurrency Level: 100
Time taken for tests: 5.059 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 17900 bytes
HTML transferred: 4900 bytes
Requests per second: 19.77 [#/sec] (mean)
Time per request: 5059.013 [ms] (mean)
Time per request: 50.590 [ms] (mean, across all concurrent requests)
Transfer rate: 3.46 [Kbytes/sec] received

Connection Times (ms)

  min  mean[+/-sd] median   max

Connect: 3 3 0.2 3 4
Processing: 23 695 1682.3 57 5054
Waiting: 23 695 1682.3 57 5053
Total: 26 698 1682.3 61 5057

Percentage of the requests served within a certain time (ms)
50% 61
66% 66
75% 66
80% 67
90% 5008
95% 5055
98% 5057
99% 5057
100% 5057 (longest request)

Java (100 users, 100,000 requests)

Concurrency Level: 100
Time taken for tests: 71.149 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 20100000 bytes
HTML transferred: 4700000 bytes
Requests per second: 1405.50 [#/sec] (mean)
Time per request: 71.149 [ms] (mean)
Time per request: 0.711 [ms] (mean, across all concurrent requests)
Transfer rate: 275.89 [Kbytes/sec] received

Connection Times (ms)

  min  mean[+/-sd] median   max

Connect: 0 0 0.7 0 47
Processing: 3 71 34.7 67 695
Waiting: 2 69 23.9 67 695
Total: 3 71 34.7 67 695

Percentage of the requests served within a certain time (ms)
50% 67
66% 68
75% 70
80% 70
90% 73
95% 77
98% 94
99% 182
100% 695 (longest request)

I ran the vibe results several times and I got the slowness several times, but one time is was extremely fast. The performance seems to be somewhat variable. Running the smaller test against the Tomcat version led to more consistent results, but slower on average. Most of the time they appear to be comparable, but the "extreme" slowness that can happen concerns me a little.

So, each request connects to Redis (May have to find a way to improve this) and returns a JSON formatted result. It's very little data, so it's mostly web-server processing from what I can tell. Watching the total system memory using htop, Tomcat uses a lot of CPU time and over 300M of memory was used whereas the vibe version used almost no CPU and total system memory usage was 101M max. Not sure how things work under the hood, but it appears that something is causing vibe to wait for some reason.

Again, if I can find some time to create a sample app to duplicate the results, I'll do so. Outside of this and the error, once I learned how to write the service, it worked very nicely.

Re: Vibe Benchmark Results

Am 29.11.2012 21:46, schrieb Casey:

Percentage of the requests served within a certain time (ms)
50% 61
66% 66
75% 66
80% 67
90% 5008
95% 5055
98% 5057
99% 5057
100% 5057 (longest request)

I've seen this happening (some of the requests take exceptionally long or time out) before and it
occurred when the request processing time reached a certain threshold and enough connection
attempts/s were made.

The libev back end (which probably is slightly out of date by now) was implemented to be able to
debug this and distinguish effects caused by libevent from those caused by vibe.d itself. But after
some optimization, the problem mostly disappeared.

I'll do another debugging session (probably some time next month) to finally get to the root cause.
Unfortunately it's a sightly annoying process because it takes some effort to identify the bad
requests within the hundred thousand good ones and the debugging on Linux usually by itself is a lot
more effort than with Visual Studio + VTune Amplifier on Windows.