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 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 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
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
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
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
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
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 3rd 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

#3: Inefficient PHP coding

Rendering content into HTML seems to be a big hotspot – at least in our application which we monitored. Looking at the PHP Execution time hotspots revealed several methods that take a very long time to execute while rendering certain aspects of the page:

Analyzing performance hotspots shows you which methods consume most of the CPU. Optimizing these methods will improve overall end user response time
Analyzing performance hotspots shows you which methods consume most of the CPU. Optimizing these methods will improve overall end user response time

If you spot a method or a PHP file, make sure you also check out the execution time variance. If you have a huge variance it is very likely that you have a data-driven performance problem, e.g: rendering a very large vs. a very small result set. In our case users that have enrolled in many courses show much higher rendering time because many of our pages also provide an overview of all courses. The question is whether we always need to render the full list.

In a production environment you should always look at the load impact on response time. The following chart compares exactly these two performance/scalability measures:

Comparing load and response time gives you a good overview of how well your application is doing. Watch out for spikes, changes in load behavior and the impact on response time.
Comparing load and response time gives you a good overview of how well your application is doing. Watch out for spikes, changes in load behavior and the impact on response time.

Key Takeaways

  • Developers: Profile your code while developing. Think about what you render out to HTML and whether all of this data is really necessary to display on every single page output
  • Testers: Make sure to test with different input data (search terms, …) as well as different types of users that have different types of data displayed in the application
  • Operations: Keep an eye on method hotspots as well as page pay load (response bytes). Notify developers when you spotted big variances in execution time and then track down the problematic input

Now it’s your turn!

Hopefully I’ve inspired you want to optimize your applications that you either built on your own, test or host. If you have questions, ask us on our free trial community forum or post a comment on this blog. Another one of our experts or I will connect with you shortly!

Developers: Watch out for these hotspots. I am pretty sure you will find some SQL queries that you can eliminate or code that can be both optimized in terms of compilation and execution time.

Testers: Use it to spot hotspots that only happen under load and detect regressions between builds that you get to test. Share the technical insight with developers.

Operations: If you find hotspots and you communicate it to the developers or client that wants you to host their PHP app use the free “sharing a session” so that they can analyze and fix the problem. An optimized version of their app will reduce your hardware requirements or allows you to host more apps on the same infrastructure.

For your Delivery Pipeline: All of these steps can be automated and therefore easily integrated in your build pipeline to act as an additional quality gateway. If you want to learn more – check out APM for DevOps and Software Quality Metrics for your Pipeline