Your old code may be presenting a performance bottleneck, or your use case may have grown beyond the capabilities the original code can provide. It is often tempting to assume the old-fashioned architecture, code style or choice of language are at fault, and conclude a rewrite is necessary using more modern technologies. However, it is worth remembering that old code was often written in times when memory, bandwidth and CPU power were less plentiful – as a result it is often capable of being just as efficient as anything modern.
A better approach may be to simply get down to detail with your existing system and identify areas where improvements can be made. The prospect of wading into obscure-looking older code can seem daunting, but often the cost of achieving familiarity is far less than the ultimate cost of a rewrite. And with our expertise in getting up to speed (pun intended!) on legacy systems, you can shave the cost further and pull the performance of your system into shape in minimum time.
Generally perfectly optimised systems only exist in theory. When high level tools are used to build processes, efficiency is sacrificed for speed of development. A highly efficient system could theoretically be developed in pure machine code – but it would not be very practical to build. Consequently for real systems efficiency can almost always be improved – but at a greater cost for a smaller gain the more the system is already optimised.
Put another way, you could go on optimising your system forever. This means it is always best to draw up some specific goals before you commit to making any changes. If you are facing a clear bottleneck in a known area then it is likely your objective will be focused on removing this – but you should really clarify what improvement you are hoping to see, and whether it is realistic. Some examples might be:
As part of our initial evaluation we will then gauge how easily we think your objectives can be met, and what changes are likely to give you the highest reward for the lowest cost.
Probably the first calculation you should do is often overlooked. What is the predicted cost of optimising your software versus simply upgrading the hardware it is running on? If switching to a faster CPU, adding more RAM or porting to SSD can meet your objectives immediately, then we would recommend giving this route serious consideration.
Please note – though we can help you with a remote software migration, we don’t deal directly with hardware and can not assist with hardware setup. However we will advise you if we think this is a good option for your situation.
For websites and web applications optimising the response delivered to the browser can often be simple and cost-effective. Some examples of how this can be done are:
Checking your site in one of the various online speed checkers (search for ‘online website speed checker’) is a good first indicator of the level of benefit your site might gain through request/response improvements. However you should be aware there are many things automated tools cannot tell you – for example, what if your nicely minimised javascript is never in fact executed, and is thus unnecessary? If you have questions about your online website speed test results, or you would like help with implementing changes then get in touch for a free initial evaluation.
[This] is a small sports forum and blog written in PHP which is taking a long time to deliver content (around 6 secs for a typical page load). The site was was written from the ground up without using a content management system… The owner has tried changing hosting provider without a noticeable performance improvement. Analysis using [an online tool] shows there are many clear ways to improve the performance of this site, including employing gzip compression, minimising scripts and taking advantage of browser caching. The biggest performance gain is likely to be the optimisation of images, which are currently very large in size… Since the site is generally serving static content, it should also integrate well with [a CDN]… It is suggested that these changes should be sufficient to improve website performance without the need for any backend performance tuning.
Manpower: 1 Developer + 1 Supervisor
Time to Completion: 1 Week
Server Downtime: None
Cost Per Hour: $45
Total Developer Hours: 14
Total Migration Cost: $630
Page loads down to less than 2 seconds
Once the low-hanging response improvements have been made, it may be time to start looking at the back end code. If your server is taking a long time to respond to requests, it is likely that significant performance improvements can be made at the back end.
Trying to find code bottlenecks usually involves running your application against a profiling tool, to get a clearer picture of which packages and routines are taking the most time to execute. It is usually possible to identify unnecessary processes, or processes which are suboptimal. There are a wide variety of ways code can end up inefficient, but some common practical cases are:
The potential gains of improving back-end code efficiency are usually less easy to visualise than front-end changes. If you suspect your system might benefit from optimising code then get in touch for a free initial evaluation and cost estimate.
Database operations can have a big impact on overall execution time. This is particularly true for applications with individual tables that hold large amounts of data (typically more than a million records). There are various ways databases queries can be made to execute more quickly:
You may be tempted to switch database engines (e.g. MySQL to PostgreSQL), but this is something we tend to suggest against, unless all other optimisation options have been exhausted. You may have heard that a particular database system is faster than yours – however the truth is the leading database engines each have strengths and weaknesses in different areas. It is not a foregone conclusion that an engine switch will improve efficiency – it may just be a headache that ultimately leads to no speed gain or even worse performance. Then you are still likely to need to optimise the new system.
To find out more about optimisation, and how your system in particular can benefit, get in touch for a free evaluation and cost estimate.
[This] is a set of busy SAAS e-commerce web-applications in use by a variety of US and UK retailers… The client is concerned that performance is lagging competitor products, particularly in the original legacy codebase. Both front-end webpage delivery and the various API endpoints, including those used by the mobile app, appear to deliver content reasonably efficiently… [However] several back-end components have been identified as potential performance bottlenecks. In particular:
It is proposed that initial investigation should focus on these areas, and further work discussed only if addressing these does not bring about the desired performance improvements.
Manpower: 8 Developers + 2 Supervisors
Time to Completion: 6 Weeks
Server Downtime: None
Cost Per Hour: $45
Total Developer Hours: 522
Total Migration Cost: $23490
Backend speed improvements in the range 25-35%
