Measure the results of FastCGI cache
[root@ip plugins]# systemctl restart nginx
With this, you are ready to test.
Perform a benchmark test with ab.
[root@ip plugins]# ab -n 10000 -c 100 http://ec2-xxx.xxx.compute.amazonaws.com/
In my environment, requests per second was 12672.30.
|Tuning contents||Page load time||Requests per second|
|MariaDB settings||64ms (275%)||31.82|
|Translation accelerator (cache)||53ms (332%)||39.29|
|Translation accelerator (disabled)||36ms (488%)||56.78|
|Tuned settings||34ms (517%)||58.47|
|event MPM+php-fpm||33ms (537%)||60.79|
|AWS users||31ms (567%)||71.76|
|PHP 5.6+OPCache+APCu||32ms (550%)||61.84 (550.2%)|
|PHP 7+OPCache+APCu||18ms (977.7%)||148.08 (1250.6%)|
|HHVM||16ms (1100%)||195.05 (1690.8%)|
|Nginx+PHP 7||16ms (1100%)||151.07 (1344%)|
|Nginx+HHVM||16ms (1100%)||205.20 (1825.6%)|
|WP SiteManager||N/A||2566.17 (22830%)|
We can see that the requests per second in the default environment was 11.24, increased to 205.20 with the Nginx+HHVM 3.12 configuration, then increased to 12672.30 with the use of Nginx’s FastCGI cache. In other words, without page caching you can speed up WordPress 18.2x, but with page caching that increases to 1127.4x.
I believe you can pursue your goal of optimized WordPress site performance by using these techniques in your own environment.
Next time, I will introduce a WordPress virtual machine that takes all these tuning steps and combines them to make things simpler. Stay tuned!