In my last entry, I detailed the performance gains to be had from switching host providers. That’s pretty cool, but a lot can still be done within WordPress to improve performance with caching. Here, I’m going to use the URL from my previous blog post (https://ryanveach.com/280/i-switched-my-host-provider/), and I’m going to run it through similar benchmark tests to see what kind of difference that makes.
During these tests, nothing is being changed except for the caching plugin. All server variables remained constant, and no other plugins were touched at this time. This plugin will allow wordpress to generate a static html webpage to take the place of php/mysql code. Therefore, a page request will simply read a flat file that is ready to go vs execute php code and pull data from the database, limiting processing time.
Test #1: 1000 requests, single threaded
Example command: ab -n 1000 -e post_280_ssl_std.csv -g post_280_ssl_std_gnuplot.tsv https://ryanveach.com/280/i-switched-my-host-provider/
|Document Length||35424 bytes||35568 bytes|
|Time taken for tests||280.391 seconds||171.673 seconds|
|Failed Requests||389 (length)||0|
|Total Transferred||35,789,569 bytes||35,873,068 bytes|
|HTML transferred:||35,423,569 bytes||35,568,000 bytes|
|Requests per second:||3.57 [#/sec]||5.83 [#/sec]|
|Mean time per request:||280.391 [ms]||171.673 [ms]|
|Transfer rate:||124.65 [Kbytes/sec]||204.06 [Kbytes/sec]|
For this test, there were 389 failed requests based on length. Researching this error indicates it could be caused by dynamic content, and does not necessarily indicate a problem. Therefore, I’m going to ignore this figure, and assume all connections were successful.