Has anyone done some web server benchmarking on their Raspi? I don't have my Raspi yet but I'm planning on using it as a web server and I'm interested to see stats for:
If these are different for different web server software and OS combinations I'd also be interested to see a comparison.
I expect that, as Alex says, the benchmarks will show that the fastest Linux webservers will still be the fastest, regardless of architecture.
If anyone wants to run benchmarks then the following tutorial has been useful to me:
How to perform benchmarks on a web-server
I have tested the RPi using Apache serving a simple static page:
<h1>It works!</h1>
As a control group I used my primary webserver which totes the following spec;
Intel(R) Xeon(R) CPU X3323 @ 2.50GHz
384MB RAM
The results are as follows:
Control
ab -n 1000 -c 5 http://www.ivings.org.uk/~james/index.html
Server Software: Apache/2.2.14
Server Hostname: www.ivings.org.uk
Server Port: 80
Document Path: /~james/index.html
Document Length: 19 bytes
Concurrency Level: 5
Time taken for tests: 17.767 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 294000 bytes
HTML transferred: 19000 bytes
Requests per second: 56.29 [#/sec] (mean)
Time per request: 88.833 [ms] (mean)
Time per request: 17.767 [ms] (mean, across all concurrent requests)
Transfer rate: 16.16 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 42 44 0.8 44 50
Processing: 44 45 0.9 45 59
Waiting: 44 45 0.9 45 59
Total: 86 89 1.3 88 108
Percentage of the requests served within a certain time (ms)
50% 88
66% 89
75% 89
80% 89
90% 90
95% 91
98% 91
99% 94
100% 108 (longest request)
Raspberry Pi
ab -n 1000 -c 5 http://86.137.189.68/index.html
Server Software: Apache/2.2.22
Server Hostname: 86.137.189.68
Server Port: 80
Document Path: /index.html
Document Length: 19 bytes
Concurrency Level: 5
Time taken for tests: 23.186 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 304000 bytes
HTML transferred: 19000 bytes
Requests per second: 43.13 [#/sec] (mean)
Time per request: 115.930 [ms] (mean)
Time per request: 23.186 [ms] (mean, across all concurrent requests)
Transfer rate: 12.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 40 44 5.6 43 116
Processing: 49 71 156.1 57 2157
Waiting: 47 53 6.7 55 104
Total: 91 116 156.1 99 2198
Percentage of the requests served within a certain time (ms)
50% 99
66% 100
75% 100
80% 100
90% 102
95% 126
98% 150
99% 667
100% 2198 (longest request)
Conclusion
Note: This is best treated as an estimate.
The results show that the Raspberry Pi actually performed damn well considering. It was only slightly less responsive than my primary webserver.
It should be fine handling a reasonably large number of requests.
Apache is not the best choice when serving static content, nginx is better suited for that. I did a benchmark using http://lekensteyn.nl/index.html as test document. It is a larger document than Jiving's example since 19 bytes is not realistic for an actual page. The results are quite amazing, the RPi even outperforms my work laptop (maybe because I have all kinds of kernel debugging switches enabled).
Here is nginx 1.4.1 running on Arch Linux (RPi, access_log off, wired ethernet):
$ ab -n 1000 -c 5 http://192.168.2.10/index.html
Server Software: nginx/1.4.1
Server Hostname: 192.168.2.10
Server Port: 80
Document Path: /index.html
Document Length: 2159 bytes
Concurrency Level: 5
Time taken for tests: 2.341 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 2392000 bytes
HTML transferred: 2159000 bytes
Requests per second: 427.18 [#/sec] (mean)
Time per request: 11.705 [ms] (mean)
Time per request: 2.341 [ms] (mean, across all concurrent requests)
Transfer rate: 997.86 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.1 1 1
Processing: 4 11 1.0 11 20
Waiting: 3 11 1.0 10 19
Total: 4 12 1.0 12 21
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 12
95% 12
98% 17
99% 18
100% 21 (longest request)
This is my laptop (access_log off, wired ethernet):
Server Software: nginx/1.4.1
Server Hostname: 192.168.2.12
Server Port: 80
Document Path: /index.html
Document Length: 2159 bytes
Concurrency Level: 5
Time taken for tests: 2.593 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 2392000 bytes
HTML transferred: 2159000 bytes
Requests per second: 385.62 [#/sec] (mean)
Time per request: 12.966 [ms] (mean)
Time per request: 2.593 [ms] (mean, across all concurrent requests)
Transfer rate: 900.79 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 3.4 5 82
Processing: 3 7 5.6 6 86
Waiting: 3 7 5.5 5 82
Total: 6 13 6.8 12 94
Percentage of the requests served within a certain time (ms)
50% 12
66% 13
75% 14
80% 15
90% 17
95% 19
98% 24
99% 34
100% 94 (longest request)
For completeness, my remote server. It is slower with the WAN connection being the likely bottleneck (access_log is not off either):
Server Software: nginx/1.2.8
Server Hostname: lekensteyn.nl
Server Port: 80
Document Path: /index.html
Document Length: 2159 bytes
Concurrency Level: 5
Time taken for tests: 11.074 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 2370000 bytes
HTML transferred: 2159000 bytes
Requests per second: 90.30 [#/sec] (mean)
Time per request: 55.371 [ms] (mean)
Time per request: 11.074 [ms] (mean, across all concurrent requests)
Transfer rate: 209.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 25 27 2.3 26 59
Processing: 28 29 2.3 28 59
Waiting: 26 27 2.4 27 59
Total: 53 55 3.8 55 102
Percentage of the requests served within a certain time (ms)
50% 55
66% 55
75% 55
80% 55
90% 56
95% 57
98% 59
99% 86
100% 102 (longest request)
With more concurrency and higher requests count, the numbers should be more reliable as more samples can be included (when I ran ab against my laptop in wires/wireless mode, its numbers fluctuated highly). Note that when testing with access logs on, that file system buffers cause unpredictable write delays when the log directory is on the SD card.
