rails5 异步_with通过异步缓存写入来加速我们的Rails应用

rails5 异步

At carwow our applications can be chatty, making one or several API calls to each other in order to fulfil a request. In fact, around 48% of all user-facing requests in the last 7 days made at least one API request to another one of our applications before responding.

在carwow上，我们的应用程序可能很健谈，可以相互进行一个或多个API调用来满足请求。 实际上，在过去7天内，约有48％的所有面向用户的请求在响应之前至少向我们的另一个应用程序发出了一个API请求。

One of the tools we use to reduce the strain we put between our applications is caching. We cache both at the client-side (using Rails.cache), as well as on the server-side (by putting Fastly ‘in front’ of our web servers). This allows us to reduce network overhead on the client-side as well as reduce the load on the server-side.

缓存是我们用来减轻应用程序之间压力的工具之一。 我们在客户端(使用Rails.cache )和服务器端(通过将Fastly放在Web服务器的“前面”)都进行缓存。 这使我们可以减少客户端的网络开销并减少服务器端的负载。

Around 73% of our requests end up being served from the client-side Rails.cache and while investigating some particularly slow endpoints I found myself unable to account for ten-to-a-hundred-ish milliseconds of processing time. Using honeycomb to investigate a couple of specific traces I could see our applications spending some amount of time between getting a response and continuing on with execution, I just didn’t know what it was spending it on! As it turns out, there are two main things we do via middleware on our HTTP Clients: caching and parsing. I’m going to focus on the caching part in this post, but the parsing part had just as much to do with these unaccounted milliseconds (perhaps more on that in a separate blog post 😉).

我们大约有73％的请求最终由客户端Rails.cache并且在调查一些特别慢的端点时，我发现自己无法占用十到一百毫秒的处理时间。 使用honeycomb调查一些特定的痕迹，我可以看到我们的应用程序在获得响应和继续执行之间花费了一些时间，我只是不知道它花了多少钱！ 事实证明，我们通过HTTP客户端上的中间件完成了两项主要工作：缓存和解析。 在本文中，我将重点介绍缓存部分，但解析部分与这些未说明的毫秒有很多关系(也许在单独的博客文章more中有更多讨论)。

Something I’ve learned to do during optimisation work is to think of all the changes we intend to make as experiments, and that means taking a lot of measurements. It's only by measuring that I can have confidence that the changes I made had the intended impact. So how can we measure the impact of cache writes?

我在优化工作中学到的一件事就是考虑我们打算作为实验进行的所有更改，这意味着要进行大量测量。 只有通过衡量，我才能确信所做的更改会产生预期的影响。 那么我们如何衡量缓存写入的影响呢？

By making use of the cache_write.active_support notification and pushing the results of that to honeycomb, I was able to get a view of how long we usually spend on caching.

通过使用cache_write.active_support通知并将其结果推送到蜂窝，我可以了解我们通常在缓存上花费的时间。

It turns out that actually it wasn’t awful. As the figure below shows, the P99 was around 15ms, but wouldn’t it be nice if that was closer to 0ms?

事实证明实际上并不糟糕。 如下图所示，P99约为15毫秒，但是如果接近0毫秒不是很好吗？

Time taken for cache writes

缓存写入所花费的时间

We shouldn’t be holding up any requests in order to update our cache, it should be best-effort and eventually consistent.

我们不应该暂停任何请求以更新我们的缓存，这应该是最大的努力，并且最终是一致的。

In order to facilitate this behaviour, we built ActiveSupport::Cache::AsyncWriteStore which wraps an existing cache-store implementation and overrides its#write method to push its work to a thread-queue instead of executing synchronously.

为了简化此行为，我们构建了ActiveSupport::Cache::AsyncWriteStore ，该包装封装了现有的缓存存储实现，并覆盖其#write方法将其工作推送到线程队列，而不是同步执行。

To test the effectiveness of this change we rolled it out to 50% of our application servers and had a look at overall performance impact on web requests. We saw some pretty good gains!

为了测试此更改的有效性，我们将其部署到了50％的应用程序服务器中，并考察了对Web请求的整体性能影响。 我们看到了一些不错的收获！

Results of an even/odd test, odd dynos (false / orange) had asynchronous cache-writes enabled via ActiveSupport::Cache::AsyncWriteStore

偶数/奇数测试结果，奇数测功(假/橙色)通过ActiveSupport :: Cache :: AsyncWriteStore启用了异步缓存写入

Overall P99 was ~100ms faster and P95 ~20ms. Every little bit helps!

总体而言，P99快100毫秒，P95快20毫秒。 一点点帮助！

Writing to cache asynchronously may be a nice and relatively easy way to chop off some of the overhead of caching while still maintaining the benefits!

异步写入缓存可能是一种不错的方法，并且相对容易，可以消除缓存的一些开销，同时又能保持优势！

One thing to take into account is that this adds another pool of threads for your Ruby process to manage, which may have an adverse effect on overall performance as ruby still needs to do those writes as some point. Effectiveness might vary based on specific use-cases for your application!

要考虑的一件事是，这将为您的Ruby进程添加另一个线程池来管理，这可能会对整体性能产生不利影响，因为ruby仍然需要在某些时候进行这些写操作。 有效性可能会因您的应用程序的特定用例而异！

Thanks for taking the time to read this post! Let me know what you think, and please leave any questions in the comments below or on twitter @CGA1123 😃

感谢您抽出宝贵的时间阅读这篇文章！ 让我知道您的想法，请在下面的评论中或在Twitter @ CGA1123上留下任何问题 😃

Until next time 👋

直到下次time

翻译自: https://medium.com/carwow-product-engineering/speeding-up-our-rails-apps-with-asynchronous-cache-writes-3eaab3e1c26

rails5 异步