The Raspberry Pi web server speed test(jeremymorgan.com)
jeremymorgan.com
The Raspberry Pi web server speed test
http://www.jeremymorgan.com/blog/programming/raspberry-pi-web-server-comparison/
10 comments
What is ruining the performance and why is it default?
One example as one of the commenters noted was prefork being the default mpm. Something else valuable for static performance is allowoverride none (disable htaccess checking).
As to why it is default, I suspect due to the popularity of php and other modules which often misbehave on the threaded worker mpm.
Maybe Apache should have a braindead on/off setting, so it works better than Nginx after a single tweak.
His testing is very flawed. Look at the availability chart: nginx has higher availability at 200 concurrent connections than at 100? It's simply not possible if the test was the same w/ just a higher concurrent connection count, as he claims.
Edit: Yes, it's "possible" that this is something in the nginx code causing it work weird, but I'd say a benchmarker should use some common sense instead of blind reporting, notice that this is an anomaly, and re-test. Benchmarking should be a scientific statistical process, reporting mean and mode, standard deviation, etc. The background environment should be heavily studied and documented to ascertain no background/cron tasks are taking place, and every little detail should be carefully looked at before putting results up for the world to see.
Edit: Yes, it's "possible" that this is something in the nginx code causing it work weird, but I'd say a benchmarker should use some common sense instead of blind reporting, notice that this is an anomaly, and re-test. Benchmarking should be a scientific statistical process, reporting mean and mode, standard deviation, etc. The background environment should be heavily studied and documented to ascertain no background/cron tasks are taking place, and every little detail should be carefully looked at before putting results up for the world to see.
The charts show nginx has lower availability at 200 concurrent connections except for the large JPG test where availability is the same (97.55%). The labels are goofed up on the second chart (they're off by a column), so maybe that's what confused you.
"not possible" is quite a strong claim in the realm of concurrent software, and so is "simply". Benchmarking is taking a measurements of a nondeterministic process, i.e. a statistical sample. Yes, some problem with the setup is quite likely given the result, but other explanations are possible as well. What if some threshhold for some action that helps the server deal with more concurrent connections was just not hit at 100 connections? unlikely but not imposible.
There is something very appealing in the idea of running own web server on a small, cheap device like RaspberryPI and pushing it to the limits. It's of course far more reasonable to just buy a hosting and don't bother about it, but how great would it be to host applications on your own server infrastructure? :)
The bottleneck wouldn't be the device, it'd be your internet connection. Higher latency, no uptime guarantees, bandwidth limits, contract restrictions, etc.
Plus, unless you already have a 50 or 100mbps connection at home for other reasons, getting that internet connection speed will cost you more than a VPS somewhere (usually). (And, it'd be 100mbps downstream, but your upstream would likely not be more than 10-20mbps.)
Plus, unless you already have a 50 or 100mbps connection at home for other reasons, getting that internet connection speed will cost you more than a VPS somewhere (usually). (And, it'd be 100mbps downstream, but your upstream would likely not be more than 10-20mbps.)
Could anybody explain why there is such a difference between text and image? Is this just because the file sizes are different or has that a different cause?
I really like to "out-of-the-box" comparison, but as others already have stated for apache that doesn't really make sense because apache just doesn't perform well without any configuration changes.
I really like to "out-of-the-box" comparison, but as others already have stated for apache that doesn't really make sense because apache just doesn't perform well without any configuration changes.
I feel like the load is way too high for getting relevant results. Imho it doesn't really matter if response time is 15 or 35 seconds when most users except responses in <1s.
Also it would have been nice to see some low-power x86 system for comparison.
Also it would have been nice to see some low-power x86 system for comparison.
This is nice to see. I've ran lighttpd extensively in an embedded environment and for our application it's always performed like a champ due to its really tiny memory footprint. In an embedded environment most of the time the web server is just running a UI, so it's best that it stay out of the way and leave the RAM available for the main application. However in the case where we're doing inter-device communication via HTTP, I might reconsider nginx.
Does anyone here have any experience with Cherokee (http://www.cherokee-project.com/)? I've heard good things about it but the fact that it's not represented in this test makes me think that it's not as widely regarded as others.
This article makes me curious to see how an FPGA based http server would perform.
I would've liked to see a small node.js or Go-based server. When running on an embedded device, you want maximum efficiency, and a full web-server isn't your best bet.
I literally have systems with tweaked setting doing 45k/second hits at less then 10ms latency on Apache. You can't do that with default settings because again the brain dead default settings.
I think in general tuning each of these carefully could eek out more performance on any platform especially one with such a small footprint.