Finding slow requests

Our entire Web service is based on Rails, and the application server is based on unicorn, so slow requests can have a big impact on the system.

Recently it was the Chinese New Year promotion and in order to be more timely to find the problems with the whole backend system, I made a slow request monitoring chart based on Kibana’s Visulize feature

The statistics chart shows the distribution of interfaces with the slowest response time in the past N minutes.

Optimization – the Cache

For the API /v1/ Publishers interface in the figure, there are many requests that take more than 100ms, and the interface does the following.

  1. Query the database and load a list of Publishers that barely change
  2. Render to JSON and return

The obvious optimization strategy is to cache out the database query. This step can actually get a big improvement, and ordinary optimization work may end at this step.

But there’s one special thing about this list, which can have hundreds of entries, which is relatively large. Ruby, on the other hand, is very poor when it comes to CPU intensive rendering. Therefore, try to solve the rendering problem.

Optimization – Render

Render only once.

Instead of caching the result of a database query, this time in the code to calculate the final return json, directly cache the JSON string.

Then, at render time, render the text and manually set the Content-Type to return JSON

Render plain: "string ", content_type: 'application/json'Copy the code

The effect

After completing the above two steps, the time observed in the log for a single request is reduced to about 0.8ms!

Future

This optimization is about as good as it gets in Rails, but you can go beyond that and consider statically converting data to JSON files for Nginx to manage.