It's surprising. They say that they are using the hardware AES support in the CPU too. They do mention that they are no longer able to take advantage of sendfile() which was letting the bulk of the data transfer to happen completely in kernel space.

So, in their case, they had already optimized things to such a degree that they were having a lot of throughput and very little CPU usage per byte. In fact, it's possible that on their old system the data streams wouldn't have to be touched a byte at a time, as they could be loaded into main memory via DMA from the disk and once that finished they could be transferred to the network card, again via DMA. Once sendfile() is called, no further context switches are necessary for that request.

Testing with `openssl speed -evp AES128` on an i5-4670K I'm able to get 6.7 gigabits of encryption out of AES-NI. I tried running two concurrent copies and they each got that speed, which tells me that it's per-core. That's easily enough speed to saturate a 10G connection.

It's quite possible that they have much older or slower hardware involved, since when you're building a server like this normally the network or disks are the limiting factor.