This is an old revision of the document!
Network Bottleneck on Cached Sites
You may already know you should look for the ''X-LiteSpeed-Cache: hit'' header before doing any page load test or benchmark test. Sometimes, you can see X-LiteSpeed-Cache: hit
header for the page, but it still seems the server has not reached the maximum capacity as it should. A network bottleneck might be to blame.
To understand how a network bottleneck may cause inferior performance, you can run an ab
benchmark test inside of your server, and again outside of your server to compare the difference. When a CDN server is used, such as CloudFlare, you may also disable that for a test to see how LiteSpeed cache can maximize your site's performance.
The following example comes from a real customer who is running a high traffic WordPress media website. LiteSpeed Cache has been enabled properly and verified through the X-LiteSpeed-Cache: hit
header. The server load is very low, and the response time is faster than it would be without cache, but it's still relatively slow. Why is the server not as fast as expected?
The website is running through CloudFlare, so we will run three separate AB tests to identify the page load problem.
1. Disable CloudFlare and Run AB Inside Server
First, disable CloufFlare by overriding it in /etc/hosts
.
<Server IP> testdomain.com
(Replace <Server IP>
with the actual IP address of your server.)
Use Curl to verify the header before testing. You can see Server: LiteSpeed
and X-LiteSpeed-Cache: hit
[root@server home]$ curl -I https://testdomain.com/
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Link: <https://testdomain.com/wp-json/>; rel="https://api.w.org/" Link: <https://wp.me/7AAok>; rel=shortlink Etag: "783430-1545084789;;;" X-LiteSpeed-Cache: hit Date: Mon, 17 Dec 2018 22:21:38 GMT Server: LiteSpeed Vary: User-Agent X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Alt-Svc: quic=":443"; ma=2592000; v="35,39,43,44" Connection: Keep-Alive
Run an ab
test with the following command inside the server:
[root@server home]$ ab -n 10000 -k -H "Accept-Encoding: gzip,deflate" -c 100 https://testdomain.com/
It returns:
Requests per second: 2883.60 [#/sec] (mean)
This number reflects the performance LiteSpeed Cache can give to your website.
2. Enable CloudFlare and Run AB Inside Server
Removing the /etc/hosts
override by commenting it out. This will allow CloudFlare to be used once again.
#<Server IP> testdomain.com
Use Curl to verify the header before testing. You can see X-LiteSpeed-Cache: hit
and Server: cloudflare
.
[root@server home]$ curl -I https://testdomain.com/
HTTP/1.1 200 OK Date: Mon, 17 Dec 2018 22:24:06 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Set-Cookie: __cfduid=d8aaaf9ae0b813d1d386e38a872fae1651545085446; expires=Tue, 17-Dec-19 22:24:06 GMT; path=/; domain=.actu17.fr; HttpOnly Link: <https://testdomain.com/wp-json/>; rel="https://api.w.org/" Link: <https://wp.me/7AAok>; rel=shortlink X-LiteSpeed-Cache: hit Vary: User-Agent X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Alt-Svc: quic=":443"; ma=2592000; v="35,39,43,44" X-Turbo-Charged-By: LiteSpeed Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Server: cloudflare CF-RAY: 48accc48e8d0a8a5-CDG
Run an ab
test with the following command inside the server:
[root@server home]$ ab -n 10000 -k -H "Accept-Encoding: gzip,deflate" -c 100 https://testdomain.com/
It returns:
Requests per second: 756.89 [#/sec] (mean)
This means the network between CloudFare and your backend server has slowed down the page load speed already.
3. Enable CloudFlare and Run AB Outside Server
Keep CloudFlare enabled and run an ab
test from a box outside of your server.
Use Curl to verify the header before testing. You can see X-LiteSpeed-Cache: hit
and Server: cloudflare
[root@test10g ~]# curl -I https://testdomain.com/
HTTP/1.1 200 OK Date: Mon, 17 Dec 2018 22:26:50 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Set-Cookie: __cfduid=df35561c1ee3b2e4b3d8f09d959ed782d1545085610; expires=Tue, 17-Dec-19 22:26:50 GMT; path=/; domain=.actu17.fr; HttpOnly Link: <https://testdomain.com/wp-json/>; rel="https://api.w.org/" Link: <https://wp.me/7AAok>; rel=shortlink X-LiteSpeed-Cache: hit Vary: User-Agent X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Alt-Svc: quic=":443"; ma=2592000; v="35,39,43,44" X-Turbo-Charged-By: LiteSpeed Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Server: cloudflare CF-RAY: 48acd048aa8bc5de-EWR
Run an ab
test with the following command outside the remote server, such as your local box:
[root@localtest ~]# ab -n 10000 -k -H "Accept-Encoding: gzip,deflate" -c 100 https://testdomain.com/
It returns:
Requests per second: 265.26 [#/sec] (mean)
Conclusion
By comparing the above tests, you can see the speed (2883.60 [#/sec]) LiteSpeed Cache can bring to your server, but in the end the site is slow (265.26 [#/sec]). It looks like there are some significant delays over the network where your server is located. Troubleshooting network issues is out of LiteSpeed's support scope, but you will ultimately need to address it before you can utilize the max performance LiteSpeed and LiteSpeed Cache can bring to you.