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.

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.

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.

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)

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.

  • Admin
  • Last modified: 2018/12/18 20:30
  • by Lisa Clarke