Try to avoid network bottleneck even LSCache enabled

You may already know you should check ''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 seems the server has not reached the max capacity as it should. Network bottleneck might be the likely reason for most of the cases.

To understand how network bottleneck may cause a slow performance issue, you can run ab benchmark test inside of your server and outside your server to compare the difference. When CDN server used, such as ClareFlare, you may also disable it for a test to see how LiteSpeed cache can maximize your site performance.

The following showcase comes from a real customer who running a high traffic media WordPress website. LiteSpeed cache has been enabled properly and verified through X-LiteSpeed-Cache: hit header. The server load is very low but the page load speed/response time is faster than without cache but still relatively slow and not as fast as expected. Why?

The website is running through CloudFlare. The following tests can be run to identify the page load problem.

First, disabling CloufFlare by overriding /etc/hosts with

<Server IP> testdomain.com

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

then run 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)

which is the performance LiteSpeed Cache can accelerate to your website.

Second, removing /etc/hosts overriding, which will enable CloudFlare back. You will need to comment out the override:

#<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

then run 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)

which means the network between CloudFare and you bankend server slow down the page load speed already.

Keep CloudFlare enabled and run ab test outside of your remote server, such as your local machine.

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

then run 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)

By comparing the above tests, you can see how fast (2883.60 [#/sec]) LiteSpeed cache can bring to your server but how slow you get in the end (265.26 [#/sec]). Looks like there are some significant delays over your network where your server located. Troubleshooting network issue is out of LiteSpeed support scope but you will ultimately need to address/fix it to be able to utilize the max performance LiteSpeed and LiteSpeed cache can bring to you.