Do you have a PHP application running and have to deal with inconveniences like lack of scalability, complexity of debugging, and low performance? That's bad enough! But trust me: you are not alone.

I've been developing Spelix, a system for cave management, for more than 20 years. It originated from a single user DOS application, and has now emerged into a web application with hundreds of users, used nationwide as the official cave directory in Austria.

Just as many software projects: Spelix evolved from MS DOS to PHP-powered Web 2.0 with increased demand for functionality and scalability

Recently I applied for a job at Compuware. For a presentation during my job interview I prepared a case study about how to monitor and improve performance of Spelix with dynaTrace, a tool in Compuware APM's suite. I found more hotspots than expected, and it was much easier than expected to resolve them. I also killed two birds with one stone: Spelix is really performing now and I've got a cool, new job.

Let me share with you my experiences in that process and the best practices I've applied to bring spelix.at to its current stage.

The Challenge of Software Evolution
When we start to design a new application we have the chance to consider data volume, number of users, traffic, all of these thoughts that drive us in selecting the proper architecture. But not many of us are able to follow that procedure, because we have to deal with a grown application. A system has emerged from a tiny set of tools and scripts, more and more functionality has been added over the years. Optimization processes often concentrate on the PHP core app to create performing database access, processing and content rendering, but that's not enough. Unfortunately other tiers are not included in these processes. Too often on the client side, the brush-up ends after designing a new frontend, using existing JavaScript plugins, and not thinking about application performance. But a slow database or browser code can dramatically slow down your application, even with an optimized PHP core.

In Spelix I have identified six major scopes for performance optimization:

1. Database
2. Server Side Data Caching
3. Client Side Data Caching
4. Network Traffic
5. Browser / CDN Cache
6. Server Side Session Handling

To be more digestible, this blog is split into two. This post focuses on the first three performance improvement steps and the next one focuses on the last three.

Step #1: Optimize Database Access
In the early stages of an application, it may not be relevant how your database access is designed. As long as the amount of data is low, a poorly designed query or missing indexes may not really affect overall response times. Therefore, database performance is rarely a topic that comes up in many cases. Once it has become an issue, it may be rather complicated to be handled. It's important to place enough value in your database design right from the start. Here are some of my lessons learned and best practices:

Interaction of Views & Indexes
I don't want to get into too much detail about creating indexes as many other articles have covered this. But it's rather important to understand when an index is not used: be careful when using views in MySQL!

When should you use views? Views are perfect to create complex queries and store them for further use. Views are commonly used to prepare data for presentation, or even for data pre-selection based on user access rights.

When should you avoid views? While a WHERE clause on a simple view may cause an index to be used, this could fail in complex view, even though the WHERE clause is on the primary key for the primary table. Once your query gets too complex, MySQL creates a temporary table for the result of the view, and then applies the query on top of the view, without any indexes to be used. Be alert when your view contains commands like GROUP_BY, ORDER_BY, or UNION. So what? My key advice on this is: when you create a view, define possible WHERE clauses and check the execution plan in the database by using the EXPLAIN command. If your WHERE clause is on a column in a table marked as select type "primary", you are on the save side to use the view. If it's "derived" or "dependent subquery", your query might not use existing indexes. It could be better to execute the query code from the application. If you have executed the SQL statements directly from your business logic, create a data access layer that contains your query code. Consider executing multiple SQL statements and merge the data in your PHP code rather than using complex joins that may spoil your indexes.

Check and Eliminate Redundant Statements
Check if your SQL executions are really necessary! You might have executed your statement in an earlier stage, is there really a requirement to run it again? Would it make sense to keep the data in your current context instead of re-requesting it? The following screenshot shows the database statements executed by the PHP Application.

A very good metric is "Executions per calling Transaction" which makes it easy to highlight statements, which are called several times, maybe too often per transaction. If that number is greater than 1, you might want to dig deeper into your code and try to optimize that. In this example "select * from sys2" reads the settings for the current user, which is not going to change permanently. There is no requirement to run this query redundantly.

What to look for? Find your query invocations in your code and avoid repetitive executions.

Optimizations? Depending on the type of information, consider caching your data in your transaction, session storage or overall server side cache, as described in the next section.

Seeing the actual SQL Statements in the context of the request makes it easier to optimize executions of database queries.

For steps 2 and 3, and for further insight, click here for the full article.