Most Read This Week
PHP News Desk
How to Spruce Up Your Evolved PHP Application
Three performance improvement steps
Jul. 29, 2014 09:45 AM
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
In Spelix I have identified six major scopes for performance optimization:
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
Interaction of Views & Indexes
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
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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads