There are several reasons for this phenomenon; 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. Clients often comment that their competitors have faster applications that are essentially shops or portals.
Clients also intend to implement cutting edge technology including shops, portals, CRMs, CMSs, Intelligent Systems, Analytical Systems, Business Intelligence Systems etc. as upgrades of slow outdated systems that cannot manage too many users or clients. The 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 in web development at some point in their career may have encountered a very common issue with applications known as performance bottlenecks. With applications going live and with the addition of historical data, complexities arise both in relation to data and applications. Moreover, with the evolution and transformation of business logic and requirements overtime and accordingly core business processes undergoing enhancements, an application may not be able to cope and would inevitably be sluggish.
Solutions include opcode caching, file caching, database query caching, query optimization, database optimization, upgrading to lightweight and faster performing front end JS library, minifying scripts and stylesheets, upgrading hardware, moving to a cloud based environment, migrating to big data platform and so on. With so many implementation options to choose from, taking a decision regarding the option that would actually solve the problem is a difficult choice. The truth is all of the options are vital at some point or the other.
Enhancement of performance is a never-ending process and is far more effective if it is proactive in comparison with performance patchwork to enhance performance when performance is below standard. Ideally, performance tuning and optimization should occur at the outset. Let’s take baby steps in the journey of performance enhancement of web applications. Optimizing performance at the code level is the first thing that should be done.
To do this, we need a tool known as Code Profiler to measure the performance of every line that is written at the server side. 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, as well as create a call graph or a call stack.
Code profiler is an useful tool for the analysis of codes in relation to bottlenecks or 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. for example are passive profilers. Let’s start with Xdebug. XDebug: Official link: http://www.xdebug.org/
It’s a PHP extension in general and a Zend extension in particular that needs to be installed. The path has to be mentioned in the php.ini file like zend_extension=”/usr/local/php/modules/xdebug.so”. After installing and restarting the webserver and by going back to the 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 this cachegrind files for example in KCacheGrind in Linux, QCacheGrind in Mac and Windows, WinCacheGrind in windows etc., 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 of 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
Stay in tune and never miss a post when you subscribe.