Monitoring a Raspberry Pi’s WordPress Performance Tuning
Now, what would you do if you wanted to host a blog for very little money?
Right! You’d run WordPress on a Raspberry Pi. The installation is simple since the Raspberry Pi’s recommended OS is a variant of Debian.
However, your enthusiasm may be reduced when accessing your site the first time because it’s terribly slow, and as an AlertFox user you know how to put numbers to your concerns: You record a typical web session using iMacros and create an iMacros/transaction sensor in your AlertFox account.
To identify the parts of your session that may be affected by performance tuning, you also add some stopwatches for certain sub-tasks:
- Loading home page: Tell the browser to load a certain URL and wait for the site to be served completely.
- Visiting three posts: Click some links on your site that takes us to three posts served by WordPress.
- Trigger search, check for keyword: Type a search term into the site’s search, wait for the result and have iMacros identify that the result of the search is as expected.
- Back to home, open post: Click the “Home” icon and open a post from the list.
- Identify a keyword: Make sure that a certain web element (here: a textual keyword) exists on that page.
After a while you check the Multi-Step Performance Report:
The report confirms your impression: The site is just too slow. The initial home page load takes 5-6 seconds and the same is true for every page load (three sites take ~15-20 seconds). The search taking about 4 seconds matches the general picture.
Next you activate your webmaster skills (or search the net and come across this great tutorial) and give your setup a thought: WordPress is generating the site using PHP. And it does so on every request. What if we could cache PHP?
Luckily, we can (php-apc) – and the effect is dramatic:
Just look at this! The macro total runtime has been reduced from about 35 to just 15 seconds. The website actually feels usable. But didn’t we just say that WordPress generates each site again and again? On every request and even if there was no change on the site? Of course, the WordPress community knows about this and provides a solution: you install a WordPress plugin that caches the generated sites and serves static pages whenever possible.
Then you keep reloading the “Multi-step Report” in order to see the new numbers and to your surprise this is what you get:
Unfortunately this does not mean that the session is completed in the fraction of a second, but that the measurement failed completely while you were applying your changes (now you recall that installing the plugin made you temporarily change the site’s permalink structure and you struggled for some time to get it working while keeping the old link structure so the sensor would work without any adjustments).
So you wait for more results to come in (they already look promising in the sensor’s log) and finally this is Multi-Step’s way of telling you that you did a good job:
The total runtime has been reduced by another 50%. A user session that initially once took about 35 seconds now is served within 5-7 seconds.
Your Raspberry Pi based WordPress installation is officially doing great!
- For some time now, our https sensors have had t...
- An AlertFox iDrone3 beta version installer is a...
- On Friday the 22nd, between 15:38 and 16:43 UTC...