SYS-CON MEDIA Authors: Jason Bloomberg, Eric Brown, Bob Gourley, Sandi Mappic, RealWire News Distribution

Related Topics: Big Data Journal, Java, SOA & WOA, Linux, AJAX & REA, PHP

Big Data Journal: Article

Top Three PHP Performance Tips for Continuous Delivery

The top performance bottlenecks are fairly easy to spot

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:

  • High PHP Compilation Time: Our App spends up to 66% of the time in compilation
  • Bad database access patterns: Some of our web requests execute up to 592 SQL requests
  • Inefficient PHP coding: Rendering HTML lists in result pages takes 5+ seconds

If you are interested in learning more about PHP Performance, be sure to check these posts out: Basic PHP Performance Tips (Google Dev) and 5 Things to Improve PHP Performance (DZone).

#1: PHP Compilation Time
In a standard PHP installation every web request processed by the PHP engine will be compiled. The compiled code will not be cached which means PHP needs to re-compile the same code when the next request comes in. In our system we saw compilation time spikes of up to 66% of the total execution 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

Key Takeaways

  • Developers: Analyze compilation time of your PHP code to identify complex coding early on
  • Testers: Watch out for PHP Compilation Time changes from build to build to identify regressions early on
  • Operations: Use PHP Accelerators as part of your PHP deployment in order to speed up overall PHP performance

#2: Bad database access patterns
Bad database access patterns are a common theme in the blog posts we write, mainly focusing on Java and .NET Enterprise Apps. Check out DB Access Patterns Gone Wild or When It Really Is The DB To Blame.

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

Key takeaways

  • Developers: Analyze which statements get really executed by your code as well as any third-party libraries you use to access code
  • Database Engineers: Watch out for SQL Executions from PHP and sit down with engineers to optimize their SQL queries in their code. Provide guidance on SQL coding or stored procedures instead of having them execute hundreds of SELECT queries
  • Testers: When executing load tests watch out for any load-related DB access patterns. Which "static" data is queried all the time and might be better off by caching it in the application?
  • Operations: Monitor spikes in # of SQL Executions and whether that relates to a data-driven problem such as a user using a very exotic search term that results in too many SQL queries

For tip #3, and for further insight, click here for the full article

More Stories By Andreas Grabner

Andreas Grabner has more than a decade of experience as an architect and developer in the Java and .NET space. In his current role, Andi works as a Technology Strategist for Compuware and leads the Compuware APM Center of Excellence team. In his role he influences the Compuware APM product strategy and works closely with customers in implementing performance management solutions across the entire application lifecycle. He is a frequent speaker at technology conferences on performance and architecture-related topics, and regularly authors articles offering business and technology advice for Compuware’s About:Performance blog.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.