Get several more uses from your toothpaste by placing the tube in boiling water for several minutes to loosen up the toothpaste inside, then pulling the tube down across the edge of the bathroom counter to scrape all of the toothpaste from the bottom of the tube to the top.

Once this technique no longer yields more toothpaste from the tube, use a pair of scissors to cut the tube open about an inch or two from the top. Open the top part and use your toothbrush to scrape the toothpaste out of the inside of the tube.

-Associated Content

When it comes to improving performance in a PHP system, there are a few different approaches you can take.  First, find out where your system performance can best be improved – see PHP Optimization – Where to Start.  Once you know where your biggest bottlenecks are, you can try to optimize through them, but at some point, you’ll reach the limits of what optimization can do for you –  run out of toothpaste, so to speak.  There are two widely used performance techniques beyond optimization – eliminate it, or scale it out.

Optimize

Generally speaking, optimizing is getting the system to do the same thing, only faster. Optimization techniques include things like tuning the server configuration for optimal performance, refactoring the code to get better performance from PHP, Opcode caching or adding indexes to the database tables for faster reads. Optimizing is usually one of the first tools you’ll be pulling out of your bag to deal with performance issues.  But there are limits as to how far optimization will take you.

With optimization, there is the law of diminishing returns.  Your first pass at optimization may yield a 600%-800% performance improvement.  Maybe your next one will give you a 200% improvement.  The next one may still give you a 100% improvement.  With each pass, finding ways to get those big performance gains will become increasingly difficult.  At some point, you’ll be struggling to get a 5% performance boost.  Or maybe you’ll find a way to increase performance, but it will also mean the code will become unmaintainable (Even if your one supergenius coder on the team can work with it, if it’s so confusing no other programmer can, it’s unmaintainable.  More on that later).

At some point, it’s not going to be worth trying to continue down this route as your performance needs increase.  I don’t boil my toothpaste and split it open to get every last drop, I go buy a new tube of toothpaste.  Similarly, at some point, even if I know that there are still probably some performance improvements somewhere still be in the system, I’ll start looking for something other than optimization to improve system performance.  This is where elimination and scaling come into play.

Eliminate

Elimination is getting rid of your bottlenecks by finding a way to not have to execute them.  There are several different ways to do this.  Caching and using background process are commonly used ones.  Caching is probably the most common elimination technique – if there is data that does not need to be updated with every run, saving and reusing the processed information will save you from having to process it each time.  

Another common elimination technique is to take the heavy lifting off of the PHP loader and put it into separate running background process.  If there is a “heavy” process that doesn’t need to be real time, just close to real time, maybe it would make sense to have a cron job do the processing of this information.  The web user would then just look at this pre-processed information instead of processing every time.  This works two ways too – If a user uploads data, instead of waiting for it to be processed in real-time, maybe you could just hold it in a queue and tell them that it will be processed later.

Scale

Even with using optimization and elimination, or if you need to deal with real-time processes where elimination isn’t an option, you’ll reach some limits and need to be able to scale your PHP system to get better performance.  There’s “vertical scaling,” which means doing something like buying a 48-core server with a terrabyte of RAM; kind of an expensive route.  And then there’s horizontal scaling, which is setting up your system so that it can be split across multiple pieces of hardware to distribute the load.  This same technique can also be used to give you highly available redundant systems.

Designing a system to horizontally scale typically requires the most work and has the most complexity of any of these three routes. And for many PHP systems, it’s a necessary route to take somewhere in the system.  Deciding what needs to be able to horizontally scale is extremely situationally dependent.  And with the added complexity to the development and the extra development time and costs that comes with this, designing to scale in situations that don’t need it is a very poor use of resources.

Summing it up

When it comes to improving PHP performance, there are many approaches that you can take, with no blanket solutions that will solve your problems in every situation.  With each option, there are pros and cons to consider that will be impacted by many factors, anything from the deployment to the makeup of team that’s working on it.  Having a big bag of tools to approach performance issues is necessary, especially for those times you can’t rely on being able to boil out a little more toothpaste.

“Our web app is slow,” complained the boss.
“Well, I hear that using commas instead of periods with echo() makes PHP faster,” replied the code monkey.
“Well, let’s try optimizing that,” said the boss.

$100k later.
“Well, it’s still slow after that change. I guess we’ve reached the limits of PHP. Time to switch to Java.”

If you run a website that becomes successful, at some point, you’re going to run into performance issues. Heck, you may only need a single visitor with some scripts to bring it to a crawl. There are a few different approaches often used for optimizing PHP, but really only one right one. First there’s the old school way, dump in a bunch of var_dumps of script execution time and hope to find a slow spot. Not very efficient.

Then there’s what I like to call the cluster-bomb optimizing approach. These are those lists of 40 things to do to optimize PHP and the like. I call this the cluster-bomb approach because you’re just throwing a bunch of tiny optimizations all over the place hoping that you hit one that’s causing your performance issues. A lot of these recommendations will leave you with a trashed collection of unmaintainable code. A cluster-f*** of code so to speak.

Very rarely will the majority of these recommendations actually make an impact to a real-world performance issue. I know this because I regularly fix real-world performance issues, and I rarely follow most of the optimization “tips” in those lists.

And then there’s the profiling method. This I think is the only right way to begin any sort of optimization process, in PHP or any other language. For the uninitiated, a profiler is a process that will sit with your script handler and generate a detailed log of exactly what happened during a script run, how long a subprocess took, etc. You can then take this log and get a visual representation of your scripts performance. From there, it’s really easy to see where the performance bottlenecks are in the system, and give you a good idea of where the best effort could be put in optimization.

For PHP optimization and profiling, the tools that I like to use are Xdebug and KCacheGrind. Xdebug is the profiler, and KCacheGrind is the graphical reader of the profiler. First, install Xdebug on your PHP server. You’ll need to be able to generate a profiler log. You can do this by either enabling it in your core php.ini file, activating it from within your script, or, my preference, turning on the xdebug.profiler_enable_trigger setting in your php.ini so you just have to add XDEBUG_PROFILE=1 as a parameter in your URL or POST parameters, and you can generate the profiler files easily on demand.

Once you’ve generated the profiler log, open it up in KCacheGrind. This is a very powerful tool that I won’t be covering very in depth, but it does make finding problem spots in the code very simple. Using the Callee Map tab on the right side of the screen, you will see a visual representation of how long the calls in your script were for each run. The larger the box, the more time relative to the other process was spent in that process. By clicking on a box, you can see a stack trace of where that specific box is.

The visual profile of a complex OO script may look something like this

KCacheGrind Dump

The largest block there represents 17% of the run time of that script. If I wanted to improve performance of this script, I may want to look there. Or maybe this tells me that I need to optimize system performance by looking at something other than script internals. Or maybe I need to look at ways to reduce the number of calls in the script run.  Each situation has its own unique requirements, and there is often more than one good approach to solving the problem.

If you have a slow performing script with a bottleneck, you may see something more like this.

KCachegrind dump of bottlenecked PHP script

The two largest boxes there represent 80% of the total script run time. This is definitely where the script bottleneck is, and performance efforts would be best directed. Directing any effort anywhere else wouldn’t have any significant impact as it represents <20% of the script run.  In this particular case, the two boxes were a couple of sloppy SQL queries (something, btw, which isn’t even on the 40 ways to optimize PHP list). But by cleaning those up, I was able to easily do a 70% performance improvement to the script run time.

Now, a code bottleneck is certainly not going to be the cause of every problem, but it will be found with the majority of performance issue you’ll come across. And each bottleneck needs to be treated differently, more to come on that later. But by using the right tools and taking the few minutes to analyze your script, you’ll quickly gain excellent insight into how to best direct your optimization efforts.

Using these tools to find where to optimize, I was able to reduce script run time by 70% in about 20 minutes. Let’s see you do that by swapping out your double quotes for single quotes (#28).