|By Harald Zeitlhofer||
|July 29, 2014 09:45 AM EDT||
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:
- Server Side Data Caching
- Client Side Data Caching
- Network Traffic
- Browser / CDN Cache
- 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.
Dec. 11, 2016 05:00 AM EST Reads: 1,172
Dec. 11, 2016 04:45 AM EST Reads: 651
Dec. 11, 2016 04:30 AM EST Reads: 875
Dec. 11, 2016 03:30 AM EST Reads: 1,147
Dec. 11, 2016 03:00 AM EST Reads: 800
Dec. 11, 2016 02:45 AM EST Reads: 915
Dec. 11, 2016 02:45 AM EST Reads: 1,804
Dec. 11, 2016 02:30 AM EST Reads: 1,063
Dec. 11, 2016 02:30 AM EST Reads: 1,300
Dec. 11, 2016 01:45 AM EST Reads: 756
Dec. 11, 2016 01:45 AM EST Reads: 4,056
Dec. 11, 2016 01:30 AM EST Reads: 1,755
Dec. 11, 2016 01:15 AM EST Reads: 1,348
What happens when the different parts of a vehicle become smarter than the vehicle itself? As we move toward the era of smart everything, hundreds of entities in a vehicle that communicate with each other, the vehicle and external systems create a need for identity orchestration so that all entities work as a conglomerate. Much like an orchestra without a conductor, without the ability to secure, control, and connect the link between a vehicle’s head unit, devices, and systems and to manage the ...
Dec. 11, 2016 12:00 AM EST Reads: 1,133
Dec. 11, 2016 12:00 AM EST Reads: 2,403