________________________________________________________________________________
It seems to me that this is mostly benchmarking the performance of the (low bandwidth, high latency) DSL uplink, not the Raspberry Pi.
"_I have seen it dynamically compress and serve at a sustained 2.7 times per second a small webpage_"
You should be able to get a _lot_ _more_ performance out of a Rasperry Pi 3 than that! It has similar capacity to the 2000-era workhorse Sun E450
https://fanf.livejournal.com/141066.html
Yeah these numbers seem way off. I did some stress tests for my thesis and was able to get 20-90 requests per second served from a Raspberry Pi 2 running a PHP website with a PostgreSQL database, depending on the complexity of the page. An equivalent site programmed in Elixir fared even better. With plain Nginx serving a static HTML file, I could hit 1000 requests per second.
So it does seem the bottleneck here is the writer's Internet connection.
TLS probably adds significant latency here. Was your 1k RPS with TLS?
People measuring RPS (requests per second) are rarely measuring CPS (connections per second), so the TLS setup overhead would be amortized across numerous requests.
A single webpage will often load a number of asset files over the same underlying connection, so it's not like CPS is the single, entirely accurate measure and RPS is just bad or something... they're both valid, interesting numbers.
Even then, TLS setup isn't _that_ expensive, in my opinion. Someone else here mentioned 35% overhead from TLS on a Raspberry Pi, which seems high to me... but it would still be orders of magnitude better performance than what the original article on this thread was claiming.
It was not. I don't think it would bog the RPi down to 2–3 requests per second though.
Hah! I worked at a startup that deployed several E450's (and their smaller cousins, the E250's.) It's amazing how far we've come with hardware.
Some basic plots would go a really long way to make the results more understandable at a glance.
Not really stressing the parts which substantially improved in the Pi 4, so not that surprising that the results aren't drastically better.
If you can use USB 3.0, saturate a GbE link or use lots of memory then the Pi 4 is a big upgrade.
That's one thing I hope the Pi 4 successor will improve on: MicroSD for the on-board storage is a _terrible_ medium, and I cross my fingers we see it replaced by a m.2 slot.
It works surprisingly well as a Plex server.
Consider Jellyfin instead of Plex :)
Not a comment on the benchmarks themselves, but why not pre-compress the assets, and let the server simply pipe the data directly? Probably increase your throughput not insignificantly (given how prevalent compression support is in modern browsers).
I've run server machines in my home on my private connection since 2001, and I recommend this. Not only do you learn a lot, but you help keep the Internet what is's supposed to be: An global network of computers talking with each other.
I think this is a good time to plug the webring for geeks, just what you should join if you're running your website on your home connection!
I ran my own Pi0w site through the test to see how it compares. About 35% of the time is spent on SSL, similar to what this person saw.
I'm not going to remove SSL, but I'm surprised it is such a big part of the page load.
One reason why the PI can be slow here is lack of any ARMv8 Crypto Extensions and by running in 64 bit mode it can make it even slower.
https://www.raspberrypi.org/forums/viewtopic.php?p=1705614#p...
Also keep in mind that the Raspberry Pi Zero (used by the person you're responding to) has the same processor as the original Pi. I'm _certain_ that the Pi 4 does tremendously better at handling crypto than the original Pi processor.
The 64-bit versus 32-bit thing is almost certainly software wonkiness, as that forum post indicates. There's no reason the 64-bit mode should be slower than 32-bit mode for that task, and benchmarks often show that 64-bit ARM is actually measurably faster than running in 32-bit mode, due to the additional available registers and whatnot.
Are you using RSA or ECDSA certificates? RSA signing is a lot more difficult than ECDSA signing. If you're concerned about compatability with older clients, you can have dual certificates, but that can be more time consuming to setup.
I do not think the author is testing Raspberry Pi at all here. Rather the capacity of the uplink. I have Pi and know it is capable of way more on local network.
Great write up. The look and feel of this website gave me nostalgia.
Sorry, might be off topic.. but i'm a big fan of the CSS here
_I have done this in part to prove that even individuals on tight budgets can enjoy the free speech benefits of running web servers at home._
I’d caution people against running any kind of controversial thing on their home network. All it takes is a few complaints against your ISP and it will disappear unless you have some business account, and even still.
Running a .onion site over tor seems like it’d avoid this; and also still works when your ISP has you NAT’ed into a private address space - The tor server setup is pretty trivial (no harder than setting up nginx etc), the only downside (which is a pretty big downside) is that it requires extra effort from users :(