We all know performance is important, but performance tuning is too often an afterthought. As a result, taking on a performance tuning project for a slow application can be pretty intimidating – where do you even begin? In this series I’ll tell you about the strategies and technologies that (in my experience) have been the most successful in improving PHP performance. To start off, however, we’ll talk about some of the easy wins in PHP performance tuning. These are the things you can do that’ll get you the most performance bang for your buck, and you should be sure you’ve checked off all of them before you take on any of the more complex stuff.

Why does performance matter?

The simple truth is that application performance has a direct impact on your bottom line:

Follow these simple best practices to start improving PHP performance:

Update PHP!

One of the easiest improvements you can make to improve performance and stability is to upgrade your version of PHP. PHP 5.3.x was released in 2009. If you haven’t migrated to PHP 5.4, now is the time! Not only do you benefit from bug fixes and new features, but you will also see faster response times immediately. See PHP.net to get started.

• Installing the latest PHP on Linux
• Installing the latest PHP on OSX
• Installing the latest PHP on Windows

Once you’ve finished upgrading PHP, be sure to disable any unused extensions in production such as xdebug or xhprof.

Use an opcode cache

PHP is an interpreted language, which means that every time a PHP page is requested, the server will interpet the PHP file and compile it into something the machine can understand (opcode). Opcode caches preserve this generated code in a cache so that it will only need to be interpreted on the first request. If you aren’t using an opcode cache you’re missing out on a very easy performance gain. Pick your flavor: APC, Zend Optimizer, XCache, or Eaccellerator. I highly recommend APC, written by the creator of PHP, Rasmus Lerdorf.

Use autoloading

Many developers writing object-oriented applications create one PHP source file per class definition. One of the biggest annoyances in writing PHP is having to write a long list of needed includes at the beginning of each script (one for each class). PHP re-evaluates these require/include expressions over and over during the evaluation period each time a file containing one or more of these expressions is loaded into the runtime. Using an autoloader will enable you to remove all of your require/include statements and benefit from a performance improvement. You can even cache the class map of your autoloader in APC for a small performance improvement.

• Getting started with autoloading using the Symfony Classloader component

Optimize your sessions

While HTTP is stateless, most real life web applications require a way to manage user data. In PHP, application state is managed via sessions. The default configuration for PHP is to persist session data to disk. This is extremely slow and not scalable beyond a single server. A better solution is to store your session data in a database and front with an LRU (Least Recently Used) cache with Memcached or Redis. If you are super smart you will realize you should limit your session data size (4096 bytes) and store all session data in a signed or encrypted cookie.

• Encrypting PHP sessions with Suhosin
• Storing sessions in Memcached
• Using a database to persist sessions

Use a distributed data cache

Applications usually require data. Data is usually structured and organized in a database. Depending on the data set and how it is accessed it can be expensive to query. An easy solution is to cache the result of the first query in a data cache like Memcached or Redis. If the data changes, you invalidate the cache and make another SQL query to get the updated result set from the database.

I highly recommend the Doctrine ORM for PHP which has built-in caching support for Memcached or Redis.

There are many use cases for a distributed data cache from caching web service responses and app configurations to entire rendered pages.

Do blocking work in the background

Often times web applications have to run tasks that can take a while to complete. In most cases there is no good reason to force the end-user to have to wait for the job to finish. The solution is to queue blocking work to run in background jobs. Background jobs are jobs that are executed outside the main flow of your program, and usually handled by a queue or message system. There are a lot of great solutions that can help solve running backgrounds jobs. The benefits come in terms of both end-user experience and scaling by writing and processing long running jobs from a queue. I am a big fan of Resque for PHP that is a simple toolkit for running tasks from queues. There are a variety of tools that provide queuing or messaging systems that work well with PHP:

• Resque
• Gearman
• RabbitMQ
• Beanstalkd
• ZeroMQ
• ActiveMQ

I highly recommend Wan Qi Chen’s excellent blog post series about getting started with background jobs and Resque for PHP.

Leverage HTTP caching

HTTP caching is one of the most misunderstood technologies on the Internet. Go read the HTTP caching specification. Don’t worry, I’ll wait. Seriously, go do it! They solved all of these caching design problems a few decades ago. It boils down to expiration or invalidation and when used properly can save your app servers a lot of load. Please read the excellent HTTP caching guide from Mark Nottingam. I highly recommend using Varnish as a reverse proxy cache to alleviate load on your app servers.

• Varnish
• Squid
• Nginx Proxy Cache
• Apache Proxy Cache

Optimize your favorite framework

Deep diving into the specifics of optimizing each framework is outside of the scope of this post, but these principles apply to every framework:

• Stay up-to-date with the latest stable version of your favorite framework
• Disable features you are not using (I18N, Security, etc)
• Enable caching features for view and result set caching

Learn to how to profile code for PHP performance

Xdebug is a PHP extension for powerful debugging. It supports stack and function traces, profiling information and memory allocation and script execution analysis. It allows developers to easily profile PHP code.

WebGrind is an Xdebug profiling web frontend in PHP5. It implements a subset of the features of kcachegrind and installs in seconds and works on all platforms. For quick-and-dirty optimizations it does the job. Here’s a screenshot showing the output from profiling:

Check out Chris Abernethy’s guide to profiling PHP with XDebug and Webgrind.

XHprof is a function-level hierarchical profiler for PHP with a reporting and UI layer. XHProf is capable of reporting function-level inclusive and exclusive wall times, memory usage, CPU times and number of calls for each function. Additionally, it supports the ability to compare two runs (hierarchical DIFF reports) or aggregate results from multiple runs.

• XHprof
• XHGui

AppDynamics is application performance management software designed to help dev and ops troubleshoot problems in complex production apps.

Get started with AppDynamics today and get in-depth analysis of your applications performance.

PHP application performance is only part of the battle

Now that you have optimized the server-side, you can spend time improving the client side! In modern web applications most of the end-user experience time is spent waiting on the client side to render. Google has dedicated many resources to helping developers improve client side performance.

• Google Web Performance Best Practices
• Steve Souders – High Performance Web Sites

See us live!

If you are interested in hearing more best practices for scaling PHP in the real world join my session at LonestarPHP in Dallas, Texas or International PHP Conference in Berlin, Germany.

apm, appdynamics, Business Transactions, High Availability, Performance, php, php performance, profiling, Scalability, SOA, tuning

Edmunds.com, the leading online automobile resource, is in the fast lane to achieve $1.2 Million in savings using AppDynamics to monitor their web application performance. John Martin, Senior Director of Production Engineering, opens up about his road trip through managing application performance.  Martin’s operations team was able to reach goals and destinations that were not previously possible and turn “feelings into facts”, by using AppDynamics.

Driving a DevOps Culture

Martin’s goals as the leader of production engineering at Edmunds.com include maintaining a collaborative DevOps culture and keeping response times below 150 milliseconds.  “Our development team is very data-driven”, said Martin, “so it is necessary that whenever an event occurs in production that the operations teams are able to feed back actual data to development.”  With AppDynamics, the operations team is able to present “facts instead of feelings” to development.

Read the Full Post…

apm, appdynamics, DevOps, Edmunds, High Availability, ROI, SOA

When application issues land on the front page of the news you know it’s no longer just an IT problem. Application performance and availability is a key element of your organization’s brand, especially if a substantial percentage or the entire business is done online. The interesting thing about “brand value” is that it’s difficult to quantify and measure; yet everyone knows it carries tremendous weight for the organization. While there’s a constellation of elements that make up a brand such as design, quality and other key elements such as customer support, application service quality i.e. performance should be included in that equation. Let me explain.

 When I think of a company like Google, besides being “innovative” a few other words that come to mind are, “fast” and “reliable”. Now let’s take a trip down memory lane for a moment. Remember the social networking site Friendster? For those of you who aren’t unfamiliar with the pre-Facebook era, Friendster is arguably the godfather of social networking that became wildly popular back in 2002. At first glance my initial opinion of Friendster was “very cool” and “social”, and I’m sure just about everyone else who was an avid user of it shared similar sentiments.That is of course until their users began noticing a massive slow down in the site’s performance and being completely unavailable at times.

I vividly remember when I couldn’t even login at one point because their servers were completely overloaded. It didn’t take long before the perception of Friendster’s brand turned from “very cool” to a frustrating “too slow”. Some claim that this is one of the major reasons for MySpace to steal away a sizable chunk of their users who were abandoning the site in droves (fortunately, they’ve reinvented themselves and are quite popular now in Asia).

Back then, application performance problems may not have ended up on the front page of the news, but with viral effects of social media and the increasing number of people staying connected online due to mobile accessibility, don’t expect to be able to simply sweep these problems under the rug.

Consider the following stories the last few weeks:

• RBS IT Fallout leaves its customers stranded without access to their bank accounts.
• Salesforce.com hit with outage due to failure of a storage tier.
• And then, the Amazon EC2 outage.

Customers can be pretty fickle and unforgiving in today’s highly competitive environment. They expect your application service levels to be topnotch around the clock. One major outage or remarkable slowdown during the year might be permissible, but if this becomes more of the rule rather than the exception, don’t be surprised if your customers’ begin to associate your brand with an unfriendly, negative term.

Granted, not all of these issues are going to be 100% avoidable due to unpredictable natural disasters as proven by the recent Amazon EC2 outage. However, my point here is that application performance and availability should be given some serious TLC since it will probably be under increasing scrutiny from senior management. So before it appears on their radar, why not be vigilant about maintaining optimal application service levels before it hits the front page of the news or becomes an unfavorable trending topic on Twitter?

apm, APM Thought Leadership, application monitoring, Brand, Cost of application performance management, High Availability

I’m fed up of reading about Cloud outages, largely because all applications are created and managed by the most dangerous species on the planet – the human being. Failure is inevitable in regards to everything the human being creates or touches, and for this reason alone I see no news in seeing the word “outage” in IT articles with or without Cloud mentioned.

What gets me the most is that applications, infra-structure and data centers were slowing down and blowing up long before “Clouds” became fashionable. They just didn’t make the news every other week when applications resided in “data-centers”–ah, the good old days. Just ask anyone who works in operations or help desk/app support whether they’ve worked a 38 hour week; I guess the vast majority will either laugh or slap you. If everything worked according to plan, IT would be a really dull place to work, help desk would be replaced with OK desk, and we’d have nothing to talk about in the office or pub.

Read the Full Post…

Amazon EC2, apm, Application Outage, Application Performance Management, cloud, Cloud Deployment, Cloud Migration, Disaster Recovery, Fault Tolerance, High Availability, PaaS, Private Cloud, Public Cloud, Slow Application