Bugzappy's Blog

About 4 weeks ago I posted a blog entry with a long list of things to think about before exposing your code, data and CPU’s to the masses. My list is really written for people whose head is on the block if things go wrong, and is really concerned with “have you thought about all the categories of things that can go wrong?”

In this month’s FREE php|architect issue (available only in PDF), Eric David Benari provides a list of much more specific things to check on the implementation side. It almost sounds like “did you brush your teeth before going to bed?” (I say this in a good way), with things such as having your 404 and 403 pages set up properly, ensuring browser-side caching is specified correctly, serving data and files from RAM not from disk as much as possible, and more. It’s a useful list with good sample code, I recommend it to new web developers as an overview of what aspects of coding for performance deserve attention, and to more experienced coders as a handy cheat sheet.

Now for a bit of a critique. Some of these coding techniques will help a site’s quality a lot, but frankly, if you are testing, then you’ll find out about these issues earlier than at the time of going through the checklist. 

Others will increase your site’s performance by a lot, but if you are benchmarking your app to meet a specific demand, then you’ll know there is a problem (or not) before you look at the checklist.

What really matters is that (a) the way you’ve coded your app and deployed it, it will provide the expected quality of service, and (b) when you need to improve performance, you have a solid idea of how to do so (improve the code, re-code, add hardware resources.) The techniques outlined in Eric’s article are key to both.

So I’m going to stay with my more abstract checklists, along which I have very concrete toolboxes such as the “coding checklist” in Eric’s php|architect article.