In an environment where resources are limited it is important to not just be smart about how many resources you use but also the way in which you use them. I have to admit that this wasn’t something I really thought about too much until a few years ago when I had to create a web site for a nationally broadcast pop music show.
As this web site was to be visited by thousands of music fans daily and also had to display a lot of dynamic content on each page, it was important to make sure we got it right. Obviously the client wasn’t going to be too happy if the web site kept going down because it couldn’t handle the load.
The early work I did on this site required lots of database queries and, once a large number of people got on the site, response times suffered as the database server struggled under the load. I made some changes to reduce this load such as caching data that changed infrequently, seeding data through regularly scheduled off-peak scripts and consolidating database queries into more complex queries which had the net effect of significantly reducing the number of queries and hence improved performance.
In the end we had a site that, I think, ran very well and I learned a lot from the process. I was actually quite disappointed when the site was decommissioned due to a policy change by the show’s network. However, even though the web site was short lived, the effects of it have been long lasting as, ever since, I have tried to consider performance implications in all the work I do and build it in from the ground up.
The issue of performance has come up again recently as I have had to battle with a poorly performing and very complex web site that we have inherited. While we re-wrote the site last year, we still have to deal with the original database design and the immense complexity of the data requirements. As a result, some functions of the site can be very memory intensive.
An example is the search results page which, for each result, needs to drill down three levels and display an immense amount of data in a small matrix. The data required to display this was originally being returned by the search method and then iterated through and displayed for each search result.
However, while the methods for retrieving all the data were as efficient as they could be, there was just so much data to retrieve that we began having issues with the server running out of memory. The short term solution was to increase the amount of memory available to the script but obviously you cannot just keep doing this indefinitely. At some stage it’s going to start affecting other aspects of the site and, indeed, other web sites on the same server.
In the end, the solution was quite simple. I made a very quick change and, while all the same data is still being retrieved, it is being done a lot smarter. Now the search method only retrieves the main result. Then, while iterating through each result, it drills down to the deeper data levels it needs and retrieves that required information. Obviously this means that the search page now requires more database queries than it did previously but, because I am now able to re-use the same variables over and over, the peak memory usage for the page has dropped a whopping 90%! I think that’s a pretty good result.
About Jared
