Web application implementation step 6: make it fast!
RT @thibauld Web application implementation step 6: make it fast!To continue in the "how to implement great web apps" series, here the step 6: make it fast! This is a vast subject and I'll not try to be exhaustive, I'd rather make a list of checkpoints with clues on how to improve each point. Making its web app fast is key for user adoption, as there is nothing more frustating than a slow web application.
Just to be clear, when I say "fast", I mean "fast from the user perspective" because what's really important in the end is how responsive your app will feel from the user perspective. To illustrate this point, let's take the example of a web page that requires 5 secondes to load, it could be acceptable if the web page becomes usable after 1 second (from the user perspective). What would be unacceptable is a page that would require 5 seconds to be finally usable by the end user. Now what should you do to make your app fast?
Slowness can come either from :
- the backend: the server takes too much time to process the request
- the network: transporting the response from the server to the client (the user web browser) takes too much time
- the rendering: actually displaying the response received from the server takes too much time
Today we'll tackle the backend part:
Profile your application. It is necessary to measure how fast is your app and where lie the problems if it is too slow. If you're developing on a LAMP stack, there is an awesome tool for that called Xdebug. Once you have installed xdebug, all you need to do is to enable it in /etc/php5/apache2/conf.d/xdebug.ini, here's my configuration:
zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so
xdebug.profiler_output_dir = "/tmp/"
xdebug.profiler_enable = Off
xdebug.profiler_enable_trigger = 1
The output dir must be writable by apache and I encourage you to enable it only via trigger. Now if you want to profile a screen of your web application, just append the argument XDEBUG_PROFILE=1 to the list of arguements. Example:
http://dev.domain.com/a/screen/path?XDEBUG_PROFILE=1
Now, when you access the above url, a file gets created in the output dir (here /tmp/). Just open this file with kcachegrind and you'll be able to visualize exactly what has happened behind the scene to process your request.
It will be easy then to answer the following questions:
- what is being called? how many times?
- how much time does my request take?
- is my caching system working as expected?
- why is this request so slow?
- are my sql requests fast enough?
- is the framework I use adding too much overhead?
- etc....
Kcachegrind provides an incredible value to profile your web application. In the next article, we'll stay in this 'make it fast' step and talk about how to make your web app network efficient.
Stay tuned!
