Bysoft China's Blog > Your e-commerce partner

Online applications are plagued by low speed : every day, we hear about companies linking slow sales to bad responsiveness of their web site. That constrats with the fact that every single developer has a piece of advice ready on how to make a web site faster and, even, has implemented a way to keep the application running extremely fast.

It is not difficult to keep a web site fast enough : as usual, the most important is to identify the problem as early as possible, during development. Here are 5 simple tricks to spot slow code without much effort.

1. Set max_execution_time, memory_limit and long_query_time very low during development. Ideally, as low as possible : 1s, 32Mb of RAM (http://php.net/manual/en/info.configuration.php) and 1s (http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html), respectively, should be sufficient. Most frameworks are known to eat up (a lot) more than that : then, keep memory 15% above the recommended lower limit. During development, if ever those limits are reached, then there is something worth checking.

Recommendation : check the logs (php error log, mysql slow queries), and look for error on display.

2. Use a slow machine for development server. It is common that the dev server is a strong server : this is conter-productive. The stronger the dev server, the easier it will mask any algorithm shortcoming, which will prove fatal in production. If virtualization is being used, set the processor allocation to low, and much lower than real production server.

Do not mistake this with making the developer`s machine slow : this won’t speed up the web site nor the development.

Recommendation : check the logs (php error log) for time out.

3. Fill the database will a lot of data, even more than expected. If the blog expects one thousand articles, duplicate the database content up to ten thousands. First, this will test drive the import scripts, secondly, this will directly show how the application will perform later in its life. Bad queries and long loops will shows at once with too much data, and will drive you directly to the slow part. Again, low quantity of in-base data tend to mask a slow code.

Recommendation : check the logs (php error log) for time out.

4. Set up traffic load on single pages: use ab (apache benchmark, ) http://httpd.apache.org/docs/2.0/programs/ab.html or http_load (http://acme.com/software/http_load/) to emulate a mob of users hitting a single page : they request a URL and then can make any web site suffer. You can run quick tests with 5, 10 and 30 users : usually, there is no need to go beyond that, and most concurrent problems will spring out of the box at such speeds. Median execution time will give indication about the behavior of the application. It is best to focus on sensitive pages, such as login, homepage, landing page, any special attraction page.

Recommendation : mesure time every day, and keep track of it in an spreadsheet, for easy graphing.

5. Run front office speed check : Yslow (https://addons.mozilla.org/en-US/firefox/addon/yslow/) or alternatives, on the website page, to check how the media are loaded and which is the slowest, or blocking the other, preventing the page to be reactive and fast. Counting the number of elements in the page, the total amount of CSS/Javascript/media/tags will be a good base indicateur, even if rough.

Recommendation : go for A in a limited number of categories.

Any of those tests will be easy to set up, and won’t require much resources to check, and even keep track across development. It will also avoid a large number of awkward situations, where the explanation ends up being : ‘ well, it worked fine in dev…’. For all their roughness, those indicators will also be simple enough to avoid the early optimization, where the code is optimized : as we all know, `premature optimization is the root of all evil`.

Last piece of advice : don’t use them all at the same time, as this will probably way too slow to do any development.

Damien Seguy