As the number of users of web services increases, they will inevitably encounter performance problems such as slow response times and server crashes. Front-end optimization is important, but the back-end, which is responsible for fundamental data processing, is often the bottleneck.

This article provides a list of practical checkpoints for engineers working on improving backend performance for the first time.

🚨 5 checkpoints to review

Performance tuning will not be effective if performed blindly. First, check whether the following items are the cause.

1. **Isn’t the N+1 problem occurring? **
   • The N+1 problem often occurs unconsciously when using an O/R mapper (ORM). When retrieving list data, check the query log to see if you are issuing SQL that loops through related data one by one.
2. **Are the indexes properly attached? **
   • Indexes are the most directly linked to database search speed. Please set an appropriate index (single or composite) for columns that are often used in search conditions or sort conditions.
3. **Are you using your cache effectively? **
   • By caching frequently accessed but rarely updated data (such as master data) in-memory using Redis or Memcached, the load on the DB can be dramatically reduced.
4. **Are you waiting too long on calls to external APIs? **
   • If communication to a third-party API or another microservice is a synchronous process, the process will be blocked there. If possible, consider a design that uses asynchronous processing or a background worker.
5. **Are there any memory leaks? **
   • If the performance of an application that has been running for a long time gradually deteriorates, a memory leak may be suspected. Use a profiler to investigate whether there are any unnecessary object references left.

🛠️ No improvement without measurement

The worst thing to do when tuning is to “fix by guessing.” My intuition that ``I feel like it’s slow here’’ often turns out to be wrong.

First, introduce an APM (application performance monitoring) tool such as New Relic or Datadog to visualize numerically which transactions and which processes (SQL execution time, external communication, etc.) are taking time.

💡 Tuning mindset

The last thing to remember is that not everything needs to be the fastest. It is often not worth it from a maintenance cost perspective to introduce a complicated caching mechanism to shave a few seconds off a batch process that is executed only once a day.

Identify critical endpoints that are directly connected to user experience and concentrate resources on them. That’s the first step to becoming a great backend engineer. Be aware of “measurement” in your daily development and make improvements little by little.