The average lifespan of a piece of software is between nine and ten years. Web applications, however, have a rather short lifespan of approximately three years, unless there is an upgrade to revitalise them.
There are several reasons for this phenomenon: the advent of newer and faster technologies, platforms, frameworks, languages, tools etc. but above all, less than optimum performance is the reason for the short lifespan of web applications—an application that runs poorly isn’t going to last as long.
Clients also intend to implement cutting edge technology including Intelligent Systems, Analytical Systems, Business Intelligence Systems etc as upgrades of slow outdated systems. Our objective is to increase the lifespan of web applications that are undergoing development, to create value for money from a client perspective and—in turn—for us as an IT services provider.
Anyone with a sound knowledge of web development will have encountered a very common issue with applications called a performance bottleneck. A bottleneck is a particular component that is slowing down everything else. Discovering and removing bottlenecks is a key component of performance testing. Not only will it make the software run more smoothly, it can extend its lifespan by years!
Complexities can arise both in relation to data and applications. Moreover, with the evolution and transformation of business logic and requirements over time, an application may not be able to cope—if it was designed for a particular goal in 2012, it won’t be suited for a modified goal in 2015.
The best protection is prevention: well-written and properly deployed code has fewer bugs. Some solutions available to us include: opcode caching, file caching, database query caching, query optimization, database optimization, upgrading to a lightweight and faster-performing front end JS library, minifying scripts and stylesheets, upgrading hardware, moving to a cloud based environment, and migrating to a big data platform. With so many implementation options to choose from, our decision is going to vary a lot depending on the particulars of your software.
Performance enhancement is a never-ending process and is far more effective if it is proactive rather than reactive. Ideally, performance tuning and optimization should occur from the outset, and should occur at the code level first.
To do this, we need a tool known as Code Profiler to measure performance.. Profiling is about measuring the relative performance of applications at the code level. Profiling tells us the CPU usage, memory usage, time complexity, number and duration of calls per function, and creates a call graph or a call stack.
A code profiler is a useful tool for the analysis of code in relation to bottlenecks, or for generally identify the sections of code that are slow and could use a speed boost. Broadly, there are two types of profilers: active and passive. Active profilers are used during the development of the applications. They gather more data than is required, are low on performance and should not be used in production environments.
Xdebug, for example, is an active profiler that has been in the market for quite some time now. Passive profilers on the other hand are used for production environments as they have minimal effect on performance, but they gather sufficient information to diagnose the performance bottlenecks and resolve them. Xhprof, Xhgui, Linko, Blackfire, New Relic etc are passive profilers. We’d be here all day if we talked about every program on the market, so today we’re sticking with Xdebug.
It’s the PHP extension in general and the Zend extension in particular that needs to be installed. The path has to be mentioned in the php.ini file like
After installing, restarting the webserver, then going back to phpinfo, it should show xdebug as a module, which is a confirmation that the installation was successful.
Note: Xdebug is not compatible with the Zend Optimizer module or any other extension that deals with PHP’s internals (DBG, APD, ioncube etc). It should strictly be used in the development environment.
There are quite a few INI settings and PHP functions, through which time traces, track traces, memory usage, the formatted output for var_dump etc. can be obtained. As far as profiling settings are concerned, the profiler in Xdebug outputs profiling information in the form of cache grind compatible files. Various applications can be used to read these cachegrind files for example: KCacheGrind on Linux, QCacheGrind on Mac and Windows, WinCacheGrind on Windows, or by using a web-based solution like Webgrind.
With an appropriate environment for profiling, the cachegrind files are generated and stored in /tmp folder, using any of the applications mentioned above. These files can be opened for profiling. The examples in the article are from QcacheGrind.
Visualization 1: Output from a cache grind file.
Function calling time in percentage, the number of call repetition, and the call resource file path.
Visualization 2: Caller / Callee
Overall view of caller and callee and timeline of the executed script.
Visualization 3: Call Graph
If you’re a PHP developer looking to take your code to the next level, check out our blog on PHP performance optimization. If you like the cut of our jib, why not come work with us? We’re hiring PHP developers at our three sites in Kolkata, Fort Wayne IN, and Wellington NZ.
Stay in tune and never miss a post when you subscribe.