We teamed up with our friends at Jelastic to compare LiteSpeed Web Server and LSCache to NGiNX and WP Super Cache. We wanted to see how each server and cache solution performed in a production WordPress environment. These are the common questions that we were hoping to answer:
- Why is running an AB test with Keep-Alive a must?
- Why is LiteSpeed sometimes not as fast as expected?
Keep-Alive allows the initial connection to be reused, greatly increasing the requests per second a web server can handle.
Tehcnically, these are unfair comparisons, and this is why: LiteSpeed is configured to use a 4096bit key, while NGiNX uses 2048bit. The handshake cost of a 4096bit key is 5-6 times that of a 2048bit key. That's why, when using these settings without keep-alive, the LSWS benchmark isn't that impressive. While it is actually a problem in all of the benchmark tests, it's most noticeable without keep-alive, because the handshake process must be repeated so many times.
To verify the protocol is simple: when you test with the AB command, look for "SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256".
- The test for LSWS was run from the NGiNX server, and vice-versa.
- We tested using `https`.
- Cache was enabled in WordPress via the plugins, but in order to keep the caching comparison fair, we didn’t use any optimization features from either plugin.
Because LiteSpeed Cache (LSCache) is built directly into LiteSpeed Web Server, it can provide high-performance dynamic content acceleration. After pages are cached, all requests that come into the server can avoid the PHP backend. Cutting out the backend processor in this way greatly increases the requests the server can handle, while also reducing the overall server load.
As you can see, LiteSpeed outperformed NGiNX considerably in the Server Load test, handling 50,000 requests with ease.
The user demo site is already a high-scoring site, but LSCache and its features can still greatly improve the score for both Desktop and Mobile.
As often happens in production environments, there are external resources (Google reCAPTCHA, facebook.NET, Google Analytics, etc.) which cannot be controlled or modified by any cache plugin. Also, these scores would be better with a CDN in place. As our tests were run on development servers that had been cloned from a production server, we were unable to use the site's CDN because it was still in use in production.
Test Environment
We used two development servers, both of which were cloned from the same production server.
-
Server Specs
- 2 CPU Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz
- 2G RAM
-
Web Servers + Plugins
- LSWS(5.2.8) + LSCache (2.3.1)
- NGiNX(1.10.1) + WP Super Cache
-
Common Settings For Both Servers
- PHP71
- Keep-Alive
- GZip
-
Common Settings
- PHP71
- Keep-Alive
- GZip
-
CMS
- WordPress(4.9.6)
-
OS
- CentOS7
-
Network
- Public network, with bandwidth around 933MB~944MB
Note:Because these were development servers, we did not use a CDN for either one.