LiveWhale, our CMS, is essentially a module-based system. Individual modules can be provided to our customers on a per-client basis. Each module is a self-contained element, that “registers” itself in the CMS framework, thereby establishing its functionality throughout. A module is responsible for creating and managing its own data, but if it is flagged as group owned, access to that data is handled by LiveWhale’s users and groups system.

It is, of course, possible for an administrator to manage those users and groups, and should a circumstance arise in which a group should be targeted for deletion, LiveWhale automatically cleans up data associated with that group (whether it is stored in a database or the file system) so that it is not orphaned. (This is in fact the case with any piece of data which “contains” additional hierarchical data.)

The mechanism we have in place for this is simple, but it is also flexible. Each piece of associated data that has to be cleaned up by a parent marked for deletion can optionally be given to a handler deletion function. For example, if a piece of news stores an image in the file system, the handler function is activated to clean that up as well.

Eventually we added a global activity log to our CMS, LiveWhale. Activity is associated with a user and a group, making this data group owned. As it turned out, the group deletion mechanism possessed a flaw. LiveWhale’s internal delete routine initially expected the logic about what a handler function had to do, if anything, to come from the handler function itself. In fact what it needed to do was to first deduce if a handler was optimal for a particular type of data at all. The activity data made this clear, when there was suddenly a need to delete hundreds or thousands of individual pieces of data which were designed to be stored in huge quantity over a long period of time (unlike with news management, for example). Pushing the handler logic up into LiveWhale’s delete routine made it no longer necessary to perform logic a hundred or thousand times when the result was always going to be the same, and a one-off deletion procedure could alternatively be used for the bulk data.

This drives home the point that building something requires either the proper foresight to know how that system has to conform to conditions that haven’t yet come about, or ensuring that the foundation you’ve already built adjusts to appropriately handle new features as you add them. Fortunately, our LiveWhale development process utilizes a variety of monitoring tools and diagnostic tests which inspect the system closely to continually perform a sanity check on the results of code execution over the product’s development lifetime. This was a case where the system noticed the deletion flaw even before I did.

At the code level, LiveWhale is a framework, which means the same codebase is hit for many different types of requests. The question is then: how to achieve high performance with a codebase that has to perform so many tasks and is therefore code heavy. It makes sense to divide code across a handful of files. The objective here is to only load libraries when you need them. A typical request will only use a tiny percentage of the entire codebase, so there’s no need to read a great deal of code from the filesystem and eat up RAM per PHP request. Also, with a modular system like LiveWhale, it is not explicitly known what modules exist that will need to be loaded. An important optimization is one where only the first request to the server has to perform logic to determine what to load. The results of this expensive operation are cached, and all subsequent LiveWhale requests enjoy dramatic savings in the module loader.

A common problem with application frameworks is that they perform two very expensive tasks with every single page load: 1) initializing a session and 2) connecting to a database. Neither of these two should be assumed. In LiveWhale, a session is started only when a component requires it. A database connection only occurs when/if the first query to it is performed. Making your application sufficiently “smart” about if and when these initializations take place will also lead to dramatic speed improvements.

Less is more. That means you should optimize out any hit to the file system that you can, or remove extraneous database queries. Also, be wary of OO (object oriented) slowdowns. If something doesn’t need to be a class, don’t use one. Remember that calls to an object’s method are more expensive than global function calls. The same holds true for accessing an object’s properties. An obvious optimization is done when dealing with data from a foreign server. Such content should be cached as much as possible, so that rapid hits to your site don’t rely on the performance (or availability) or an external data source. Another tip would be to use error suppression (@) sparingly. This is a known performance hit. There are a number of similar, simple tips available via a quick Google search for “php optimizations”, and there are slideshows available from PHP developers on the subject.

Analyze how your code operates. If you have a function that uses a lot of logic (if/then, switch), make sure you understand what the “common case” is. In other words, what’s the most likely condition that function will come across? Then determine if the function’s logic is conducive to the fastest possible result under the most common case. For example, I had a function that has to intercept a variety of XML structures and handle them in different ways. One particular XML structure (the simplest possible one) was far and away the most common case. Rather than parsing the XML with simplexml_load_string() as I do with all the chunks of XML I receive, I first do a preg_match() to determine if I have the common case. In this situation, I can immediately return a simple result and skip both the parsing of the XML and the lengthy logic that goes with performing operations with it.

Identify “hot” functions. Functions that are called many times, often within a loop, should get the most attention in terms of optimization. First, make sure the function should be called at all, as opposed to using inline code, otherwise you needlessly acquire function overhead. Second, move any redundant logic outside of the hot function. Perhaps the check can be performed just once before the hot code is executed. There are also situations where a function can potentially be called repeatedly and end up with the same result. It might make sense to declare a static variable inside the function, to locally cache content generated by the function. On a subsequent call, it can first check the static array to see if a result already exists, and simply return that if so. This sort of fine-grained optimization will only help when there is a significant bottleneck with a particular function, but it can make a huge difference if done wisely.

Lastly, use XDebug! XDebug is your friend. Among the many things it can do, it will let you profile your PHP code and generate a report about how much time your script is taking overall and within particular functions. Here’s a mockup of the type of information it provides:

In this example, the function LiveWhale->foo() clearly takes the majority of the time for this request. At 38.3% of request time for a single call, it is a good candidate for serious analysis. LiveWhale->bar() is also expensive compared to other operations, and there may be ways to make this function perform better too. The function do_something() takes 6.3% for a single call, on line 41. Another function, do_something_else(), takes nearly the same amount of time but due to the fact that it was called 15 times (at 17 CPU cycles each, so 252 cycles total). Knowing why each function takes the time that it does, and why it might be called so many times, will help you maximize the performance of your application.

Familiarity with what makes PHP code perform well will only lead to the best decisions being made early on, so that XDebug reveals fewer inefficiencies. In the long run, many of these tips become automatic and part of your coding style, but for the best quality, production ready code, a little bit of analysis and thought goes a long way.

But at the risk of stealing some thunder from that announcement, I’d like to show off something that we’ve been spending a lot of time on:

This is the add-a-news-story page of LiveWhale, the CMS we’ve developed as an answer to problems posed in our infamous (among our clients, anyway) content management manifesto. In later posts I’ll go into some detail about specific interface choices we’ve made (a personal favorite is the flowchart behind attaching images to news stories), but for now I’ll talk about what we didn’t do.

One of the main problems with most enterprise content management solutions is their unapproachability. A simple task like a creation of a news item can be buried by layers of menus, technical jargon, and–let’s be honest–really ugly interfaces. It’s the type of interface that savvy users master through days or weeks of training and non-savvy users end up navigating by way of post-its on the side of their monitors. But you need those weeks to worry about everything else involved in your website launch; you need that space on the side of your monitor for pictures of your kids.

We set out to create an interface that minimizes the distance between what the user wants to accomplish and what she has to do. This gap is huge huge in most enterprise CMSes. Adding or editing a news story is a task that every staff member at your institution understands intuitively; why does it so often feel like piecemeal data entry?

Making the user click “Attach resource” when she wants to add an image creates a cognitive separation where one needn’t exist. So all of our instructions and labels are in plain English. Steps like having to enter the story body on one page and the contact info on another–or burying things in menus, or presenting disparate information as visually equal–create a similarly artificial distance. That’s why our news edit page looks almost like a published news page: we want the headline to jump out at you and the image to appear at reasonable size, and we want everything that appears on the frontend to appear here.

By minimizing this distance between the user’s goals and the user’s processes, we think we’ve made LiveWhale a snap to use regardless of where you fall on the scale of technical knowhow. One of these days we’ll give more of a detailed tour; but, in the meantime, let us know what you think.