As software engineers who have experience with databases and application languages, we are often asked to troubleshoot difficult performance problems. Most of those problems present in the database, and in our current tech culture, DBAs (database administrators) are usually the people who are expected to not only troubleshoot but also resolve those issues. There is a problem with that approach in general. Most DBA’s do not have experience writing the applications that are causing the problems. In fact at many companies, it’s not database people (admins or engineers) that design the database. More mature companies will involve database people in the architectural design of the entire system, but too many software/database solutions are initially built by “full-stack engineers” who dabble at everything, and may be strong at both front and back end technologies, but they have never scaled a system and don’t understand the architectural requirements needed in order to scale the system successfully.
When approaching performance tuning, everything needs to be on the table. Companies often desire to tackle the problem without changing the application code- at least at first. Sometimes they cannot change the application- it may be a vendor application installed on someone’s network with full access to the database that supports it but no access to the source code. Other times the company is too busy with customer priorities to devote energy to tech-debt. Everyone wants their cake and to eat it too. Build an application fast! Shouldn’t it just scale automatically? If only it were that easy. In today’s world, the Cloud providers have given us buttons you can click to “scale” things up easily, isn’t that enough? They don’t tell you that bad code expands to fill the space that it is given. If you gave the application / database server more memory or CPU with the click of that expensive button, you’ve bought yourself some time, but you have not solved the problem. Companies that understand this will click the button and then devote technical resources to solving the problem, or they will be clicking that button again in the near future.
There is a methodical approach to performance tuning that respects the desires of companies to not change the application code or the underlying architecture of the system. Some difficult performance problems may require a significant rewrite, but that is not where anyone should begin (**unless you are a consulting company who’s main objective is to accumulate billable hours, then that is often exactly where they begin, even when it is unnecessary. DISCLAIMER: we are not fans of most technical consulting companies, a blog on that topic is coming soon**).
If you are in need of a consultation to see how we can help you, please contact us!
