Speeding up a Slow Website – Classic ASP Code
Legacy Website Complexities
Speeding up a legacy website can be more complex than you think. Software typically has a life expectancy of three to seven years. A well designed system might last seven years while a poorly designed system will last three years, and likely much less. Many businesses have critical core business processes based on corporate software that dates back decades running COBOL, Fortran or other systems from the 1980s and earlier.
ROI to Replace a Legacy System
In many cases, the ROI to completely overhaul the system just isn’t there. Also, the individuals who built the system might be long gone and rewriting it would be a major effort. A new system means new hardware, software licensing costs and re-training staff. Not to mention the development costs of a technology team with individuals to program, project manage, test and maintain. Because of the high costs, many companies decide to stick with their legacy system and try to make it faster by throwing more and more hardware at it.
Recently a large ecommerce company came to us with a challenge. The client had a 16 year old website running classic ASP that was terribly slow. They asked us to identify quick and easy ways to make it faster. Their development teams had already implemented the basics such as optimizing images. They even built an extensive caching mechanism that generated HTML files multiple times per week. In spite of their efforts, the ecommerce processes were still extremely slow with average page load times of 30 or more seconds. With their busiest shopping season of the year approaching they needed results quickly. The client requested a complete review with a recommendations presentation within two weeks.
We approached the problem by looking at the code and the database. The fundamental issue was that the developers had tried to put as little stress as possible on the database and that resulted in a less than optimal design. In this post, I will highlight the code review and high level suggestions, and will also include a link to our detailed Classic ASP recommendations with company information redacted. In the next post, I will discuss what we recommended on the database side.
The short-term solutions focused on the following:
1. Page/scripting issues – check that best practices were followed when developing ASP pages.
2. Embedded non-optimized SQL queries – these are calls to the database
3. Unnecessary include files – code referenced by the web page that is not needed
4. Keeping database connections open after requests
In every case, there were improvements that could have been made.
Long-term solutions were to:
1. Move embedded SQL to the database.
2. Upgrade software to .NET or other modern technology
3. Improve the database capabilities