Why HTTP/2 Performance is Important
More than half of the world's websites use HTTPS for their default protocol, and this number is rising every day. The HTTP/2 protocol, which is only supported by browsers when it is served over HTTPS, is in use by more than a third of sites and is also rising in popularity.
For this reason, HTTP/2 performance is a crucial metric for any modern web server.
Benchmark vs. Nginx and Apache
In benchmark testing against nginx and Apache, LiteSpeed's HTTP/2 implementation delivered far superior results:
LiteSpeed Web Server is 10X faster than nginx and 78X faster than Apache.
Conclusions
We tested small static files, large media files, HPACK compression and HTTP/2 stream priority. LiteSpeed Web Server was consistently faster than nginx in all scenarios when serving HTTP/2 traffic.
Specifically, we had the following takeaways from our benchmarking:
4 Times Faster
1.55 Times Faster
Superior Compression
Effective Stream Priority
LiteSpeed's HTTP/2 implementation is advanced, and is constantly improving.
Why LiteSpeed's HTTPS and HTTP/2 is Special
Other servers use OpenSSL libraries which have no control over the TLS record. They cannot control the size of the record, determine when to start a new record, or when to flush out buffered records. LiteSpeed's implementation is different, because LiteSpeed does not use OpenSSL libraries. LiteSpeed handles the TLS record directly.
This gives LiteSpeed the ability to customize in important ways:
- Reduce data copies from the data buffer to the TLS record buffer.
- Adjust the TLS record size in order to deliver data quickly and improve TTFB (time to first byte).
- Combine multiple TLS records together and send over one system call. This reduces system-call overhead and reduces network-packet-level fragmentation.
- Directly build the HTTP/2 frame in the TLS record buffer to further reduce data copies.
- Implement an efficient sendfile()-like API that rivals Kernel TLS efficiency.
- HTTP/2 stream priority done right!
Other Bells, Whistles, and Improvements
The SSL handshake is the most expensive operation in SSL. Each modern CPU core can handle 400-500 handshakes per second, which becomes a major blocking factor for an event-driven server. When serving a large amount of new SSL connections, the event loop may be blocked, making the server unable to perform other tasks smoothly. By offloading the handshake to one or multiple lower-priority threads, the main event-loop thread is able to finish tasks in a timely manner.
Compressing the certificate reduces the amount of data that must be exchanged during the handshake.
