Top PHP Performance Tips for Continuous Delivery | @DevOpsSummit [#DevOps]
The top performance bottlenecks are fairly easy to spot
By: Andreas Grabner
Oct. 6, 2014 09:15 AM
Are you developing or hosting PHP applications? Are you doing performance sanity checks along your delivery pipeline? No? Not Yet? Then start with a quick check. It only takes 15 minutes and it really pays off. As a developer you can improve your code, and as somebody responsible for your build pipeline you can automate these checks and enforce additional quality gates. And as a PHP Hosting company / group you will be able optimize your deployment and run more of these apps and sustain more load on the same infrastructure.
Just like Java, .NET, and Ruby type applications, the top performance bottlenecks are fairly easy to spot and fixing them improves end user performance and saves compute power for your servers.
Here is what we discovered when analyzing our own Moodle-based educational platform using the 15 Day Free Trial of dynaTrace:
#1: PHP Compilation Time
Many of our requests spend a lot of time in compiling complex PHP files. Optimizing these files will improve overall response time
It also pays off to analyze PHP Compilation Time long term. In our case we noticed that a new deployment let the Compilation Time Contribution jump to twice of what it was before. Having this insight allows you to review your code changes as well as think off using PHP Compilation Caching using PHP Accelerators.
Warning Signal for PHP Monitoring: A change in our deployment in combination with more traffic on April 3rd caused our PHP Compilation Time contribution to double
#2: Bad database access patterns
PHP Applications face the same problems. Watch out for the N+1 Query Problem; executing the same SQL multiple times per request or requesting data with multiple SQLs instead of optimizing a single SELECT statement:
Instead of specifying a proper IN-Clause the same SQL is executed hundreds of times with different WHERE-Clause causing unnecessary DB Roundtrips
Executing the exact same SQL up to 95 times is a sign for caching the data instead of requesting it over and over again from the database
To spot these problematic access patterns in production simply monitor the number of database executions and compare them with the incoming transactions as well as total database time as shown in the following chart:
In a production environment you do not want to see many spikes in database execution count and time that don't correlate to incoming load. That would indicate a data-driven performance/architectural problem
For tip #3, and for further insight, click here for the full article
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week