CubieTruck SSL performance

08.11.2014 17:24

For years now the general consensus seems to be that the overhead of serving web sites securely over SSL is negligible compared to plain-text HTTP, at least as far as CPU load is concerned. This might be true when talking about big, dynamically generated websites served by expensive rack servers humming away in some data center. But how about serving a small blog with mostly static HTML from a small ARM-based computer? It turns out that such a view is overly optimistic.

Before moving this site to HTTPS-only today, I performed some benchmarks with my CubieTruck server. I reused the same benchmarking scripts I used back in January to estimate the number of requests Apache can handle per second for a few different types of content.

My setup today is mostly identical to what I used then. Hardware is the same CubieTruck A20 on 100 Mb/s Ethernet, although now the root filesystem is on a Samsung 840 EVO SSD. Kernel is Linux 3.4.95 for Allwinner A20 from Static content is served by Apache 2.2.22 as shipped in Debian Wheezy armhf architecture. Dynamic parts are rendered with Perl 5 and HTML::Template and served through Apache and Speedy CGI.

I compared the following two Apache configurations:

  • Plain text HTTP and
  • secure HTTPS using TLSv1 protocol, ECDHE-RSA-AES256-GCM-SHA384 cipher and 2048 bit RSA key (a reasonably secure setup according to SSL Labs).

Below are results from the Apache benchmarking tool. Numbers in parentheses show size of HTTP body (without headers).

Requests per second for static HTML.

Requests per second for dynamic HTML.

Requests per second for image.

Requests per second for API call.

As you can see, encryption unfortunately makes the server somewhere between 2 and 7 times slower. The impact is highest when serving small static files. Most likely CPU time spent in the SSL layer dominates there. On the other hand, there is less slow-down with the dynamic content where the CPU had something to do even in the plain-text case.

Can something be done to improve these numbers without degrading the cipher settings? Not much, it seems.

Relatively recently, OpenSSL in Debian was compiled on ARM without hand-optimized assembly routines. I have checked, however, and the version of OpenSSL I was using has the patch that enables them already applied (together with around 50 other OpenSSL patches that Debian ships with these days).

The Allwinner A20 SoC appears to have some kind of crypto hardware on board. Unfortunately, there is very little information available about it. If it could be exposed through the kernel's crypto API, it might speed things up a bit. An experimental kernel driver has been around from June this year. The remark about not using DMA however makes me a bit pessimistic regarding its usefulness at this point. I might try to set it up eventually, but it will probably be tricky. Even with working kernel support, enabling hardware acceleration for OpenSSL in this way seems to be non-trivial.

Posted by Tomaž | Categories: Code


This seems like far too huge a degradation.. was the benchmark client configured to reuse the initial SSL session key, and was Apache configured to cache those keys? If not, most time will be lost in key generation

Posted by David W

David, thanks for reminding me about SSL session cache. The cache was enabled as in the default Apache mod_ssl configuration shipped with Debian. The "ab" benchmark on the other hand doesn't seem to support session reuse. This appears to be an old patch for that, but as far as I can see, it was not applied to the version I was using:

So the answer is no, in these benchmarks there was no SSL session reuse.

Posted by Tomaž

are there a new kernel available, which uses the craypto hardware on A20?
I have a nextcloud running on cubietruck with SSL enabled, and it is slow. I think it is the SSL thingy (How to test this with "ab"? - can you tell me the command?)
Do you think an Pi3 is faster with SSL enabled, than the CubietrucK?

Posted by Eugen

Eugen, it's possible that recent upstream kernel builds from have A20 crypto hardware support. I don't know for sure. I'm still using the Allwinner kernel. Links at the end of my post are still a good start if you want to research that.

As David mentions, the "ab" tool is not a good benchmark for SSL since it doesn't do session caching like modern browsers. I don't know about any tool that does though. I would be interested in knowing if you find out!

My tests were done with something like "ab -c 10 -n 2000 -e output.csv https://..."

I don't know how SSL performance compares with Raspberry Pi 3.

Posted by Tomaž

Add a new comment

(No HTML tags allowed. Separate paragraphs with a blank line.)