Litespeed vs NGINX

NGINX vs LiteSpeed: Benchmark Testing

We ran three LiteSpeed or NGINX tests and took the median value to get each number (the requests per second or resource fetch time).

LiteSpeed or NGINX: small page fetching

This testing involved fetching the 163 byte index page in numerous ways, through multiple network conditions. Key h2load options:

• -n: Overall number of requests to be sent
• -c: Amount of connections
• -m: Amount of concurrent requests for each connection
• -t: Amount of of h2load threads

-n 10000 -c 100

	LiteSpeed	NGINX
100 mbps, 100 ms RTT	925 reqs/sec	880 reqs/sec
100 mbps, 20 ms RTT	3910 reqs/sec	2900 reqs/sec
100 mbps, 10 ms RTT	6400 reqs/sec	4150 reqs/sec

-n 100000 -c 100 -t 10 Every connection will send 1000 requests now, with this being a longer run.

	LiteSpeed	NGINX
100 mbps, 100 ms RTT	995 reqs/sec	975 reqs/sec
100 mbps, 20 ms RTT	4675 reqs/sec	4510 reqs/sec
100 mbps, 10 ms RTT	8410 reqs/sec	7100 reqs/sec

At 100ms, LiteSpeed is quite a bit faster. But its speed increases substantially at 20ms and 10ms RTT. -n 100000 -c 100 -m 10 -t 10

	LiteSpeed	NGINX
100 mbps, 100 ms RTT	9100 reqs/sec	7380 reqs/sec
100 mbps, 20 ms RTT	24550 reqs/sec	5790 reqs/sec *
100 mbps, 10 ms RTT	25120 reqs/sec	6730 reqs/sec *

* High variance It was fascinating to find in the initial test that NGINX used 100 percent CPU, when OpenLiteSpeed utilized around 45 percent CPU only. This is why NGINX’s numbers tend to not improve despite the RTT dropping. Still, OpenLiteSpeed doesn’t utilize 100 percent CPU even with 20 and 10ms RTTs. -n 1000000 -c 100 -m 10 -t 10 We had to set the NGINX http3_max_requests parameter to 10000 (from the 1000 default value) to make sure it could issue in excess of 1000 requests for each connection.

	LiteSpeed	NGINX
200 mbps, 10 ms RTT	29140 reqs/sec	7120 reqs/sec *

* High variance At this point, LiteSpeed was using 100 percent CPU. NGINX allocated in excess of 1GB of memory during this test, while LiteSpeed remained below 28MB. So, that equates to greater than four times the performance for approximately 1/37th of the price.

Single file fetching

In this situation, we fetched a single file using alternative network conditions and measured the length of time required to download it. 10MB

	LiteSpeed	NGINX
10 mbps, 100 ms RTT	9.6 sec	10.9 sec
10 mbps, 20 ms RTT	9.6 sec	10.5 sec
10 mbps, 10 ms RTT	9.4 sec	10.8 sec

It’s clear that NGINX is a little slower here. It also utilizes three to four times more CPU than LiteSpeed did in the above tests. 100MB

	LiteSpeed	NGINX
100 mbps, 100 ms RTT	11.9 sec	39 sec *
100 mbps, 20 ms RTT	9.2 sec	38 sec *
100 mbps, 10 ms RTT	8.9 sec	29 sec

*High variance Across all three of the NGINX vs LiteSpeed benchmarks, NGINX utilized 100 percent CPU. It’s highly likely this is the cause of its weaker performance. 1GB We attempted to download a 1GB file with NGINX at 1gbps. However, we became tired of waiting for the download to complete. We believe the contrast in LiteSpeed and NGINX’s respective performance was pronounced at this speed.

NGINX vs LiteSpeed: Shallow Queue

NGINX has struggled with high bandwidth, so we decided to see how it would fare with low bandwidth instead. We used a shallow queue with netem’s limit parameter and set it to seven. Single 10MB file fetching

	limit	LiteSpeed	NGINX
5 mbps, 20 ms RTT	1000 *	19.5 sec	23.1 sec
5 mbps, 20 ms RTT	7	29.5 sec	47.9 sec

*netem default We found LiteSpeed’s performance decreased by around 50 percent when we introduced a shallow queue on path. However, NGINX’s performance was degraded by more than 100 percent. So, LiteSpeed was found to be substantially faster than NGINX in both situations.