How we improved request execution time with Redis cache

Hi! As you know just a week ago we had a major release of our ClearVPN apps and I decided to share some insights and one of the problems I faced during the development. It is not a surprising that cache improves requests performance by a lot, I also knew it :) But I found it interesting by how much it can improve the numbers, so here we go.

We are using GRPC (https://grpc.io/) as our main transport (and its awesome) for apps communication with backend as well PostgreSQL with Pgbouncer as our connection pooler.

Before release with help of @anasinnyk (thanks and kudos) we did load testing of all our GRPC endpoints and the result was pretty much bad. So this is what we got with our most "heavy endpoint" - pick all shortcuts and nodes with settings for an app. For load testing we used (https://github.com/bojand/ghz) with configuration:

We got this result:

Invalidation

As shortcuts/nodes are changed manually via admin panel we need to invalidate all shortcuts cache on any CRUD operation on Node or Shortcut entity.

And here is a catch. If you want to delete all keys by pattern you need to do the following:

So,

It is pretty heavy, but good thing, Redis has async delete 'UNLINK', so it makes it more/less doable.

In other methods cache is invalidated by single key (e.g. account subscription) so it is also good for performance.

Of course, there is a scenario when we couldn't invalidate the cache for some reason, but it is resolved by TTL, so worst case scenario, there would be outdated shortcut for another 2 hours which is acceptable.

Conclusion

In most SaaS applications the bottle neck is always connections to DB. As in my case when I have complex business logic methods and complex db query with lots of joins, Redis cache showed

incredible results. But, invalidation can be challenging in some cases and you should always work negative scenarios.

If you want to know more examples or data you can always write me @buchek

✌🏻