The lifespan of a software is anywhere between two and twenty years. In contrast, the average lifespan is between nine and ten years. Kudos to the system applications or the native system applications for furthering the average lifespan of a software. The web applications, however, have a rather short lifespan of approximately three years until there is an upgrade prolonging the lifespan.
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.
Effective Web Solutions at CodeClouds
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 and Active Profilers
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/
- Display stack traces on error conditions, maximum nesting level protection and time tracking.
- Replaces the PHP’s var_dump functions to a more informative variable display.
- Can log all function calls including parameters and return values to a file in different formats.
- Code coverage tells us which lines of script (or set of scripts) have been executed during a request.
- Help to find bottlenecks in our script and visualize those.
- Xdebug provides an interface for debugger clients that interact with running PHP scripts.
- Run the PHPinfo();
- Copy the information from the browser. (Not the source code)
- Paste it in the box at http://www.xdebug.org/wizard.php and click the button with the caption “Analyse my PHPinfo() output”
- Follow the bespoke installation instruction, specifying which file to download, where to keep it, how to set up the php.ini in order to get it up and running.
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.
- xdebug.profiler_append = 0 (default 0: individual files, 1: appended to the same file)
- xdebug.profiler_enable = 0 (default 0: profiling disabled, 1: starts profiling)
- xdebug.profiler_enable_trigger (default 0: selective profiling off, 1: selective profiling on and only profiles for a request. When this setting is set to 1, we can trigger the generation of profiler files by using the XDEBUG_PROFILE GET/POST parameter, or set a cookie with the name XDEBUG_PROFILE. ex. url? XDEBUG_PROFILE will run profiling for this page only, we should set xdebug.profiler_enable = 0 if we do not want profiling for all the requests.)
- xdebug.profiler_enable_trigger_value = “” (default: “” set a key value to refer to in post/get or cookies to start profiling)
- xdebug.profiler_output_dir = /tmp (specifies where to store the profiling files)
- xdebug.profiler_output_name = cachegrind.out.%p (Stores the format for file names.)
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 callee resource file path.
Visualization 2: Caller / Callee
Overall view of caller and callee and timeline of the executed script.
Visualization 3: Call Graph