| Tuning contents | Page load time | Requests per second |
| Default environment | 176ms | 11.24 |
| APC | 70ms (251%) | 29.20 |
| OPcache+APCu | 66ms (266%) | 30.51 |
| MariaDB settings |
64ms (275%) | 31.82 |
| Translation accelerator (cache) | 53ms (332%) | 39.29 |
| Translation accelerator (disabled) | 36ms (488%) | 56.78 |
| gzip | 35ms (502%) | ─ |
| Tuned settings | 34ms (517%) | 58.47 |
| event MPM+php-fpm | 33ms (537%) | 60.79 |
| AWS users | 31ms (567%) | 71.76 |
This is the limit of performance improvement we can achieve with the standard CentOS 7 repositories and without using page caching.
Note for AWS users
Here is a "hack" for Amazon Web Services (AWS) users. When you start a new instance, the CPU your virtual machine uses it determined at launch. This means you will not always get the same CPU, just the most available one.
For example, in my case, I was first given a Xeon E5-2670 v2, but after stopping and restarting my instance several times, I got a Xeon E5-2676 v3. When I tested the site performance with this CPU I got a page load time of 31ms and requests per second of 71.76.
Next time, page caching and other techniques for more speed
I will begin to introduce tuning techniques that are outside the standard CentOS 7 repository, and also have you enable page caching to get even faster performance. You will be able to achieve the level of speed that is offered by Prime Strategy's free WordPress virtual machine KUSANAGI. Stay tuned.
