ruby-on-rails – 在后端Rails应用程序中使用Puma和Sidekiq

发布时间：2020-12-17 03:55:29 所属栏目：百科来源：网络整理

导读：我有一个带Sidekiq的后端Rails服务器,它用作API服务器.该应用程序如下工作： My Rails服务器同时从传入的API客户端接收许多请求. 对于这些请求中的每一个,Rails服务器都会将作业分配给Sidekiq服务器. Sidekiq服务器向外部API(例如Facebook)发出请求以获取数

我有一个带Sidekiq的后端Rails服务器,它用作API服务器.该应用程序如下工作：

> My Rails服务器同时从传入的API客户端接收许多请求.
>对于这些请求中的每一个,Rails服务器都会将作业分配给Sidekiq服务器. Sidekiq服务器向外部API(例如Facebook)发出请求以获取数据,并对其进行分析并将结果返回给Rails服务器.

例如,如果我从API客户端收到10个传入请求,则对于每个请求,我需要向外部API服务器发出10个请求,获取数据并对其进行处理.

我的挑战是让我的应用程序同时响应传入的请求.也就是说,对于每个传入的请求,我的应用程序应该并行处理：调用外部API,获取数据并返回结果.

现在,我知道Puma可以为Rails应用添加并发性,而Sidekiq是多线程的.

我的问题是：如果我已经拥有Puma,我真的需要Sidekiq吗？使用Puma和Sidekiq会有什么好处？

特别是,使用Puma,我只是从我的Rails应用程序调用我的外部API调用,数据处理等,它们将自动并发.

解决方法

是的,你可能想要使用Puma和Sidekiq.这里真的有两个问题.

并发(您似乎已经知道)是可以同时处理的Web请求数.使用像Puma或Unicorn这样的应用服务器肯定会帮助您获得比默认Web砖服务器更好的并发性.

另一个问题是服务器处理Web请求所需的时间长度.

这两件事情相关的原因是应用程序可以处理的每秒数量或请求数量是每个请求的平均处理时间和接受请求的工作进程数量的函数.假设你的平均响应时间是100毫秒.然后,单个Web工作者可以每秒处理10个请求.如果你有5个工人,那么你每秒可以处理50个请求.如果您的平均响应时间是500毫秒,那么您可以使用一名工作人员处理2 reqs / sec,并且可以使用5名工作人员处理10 reqs / sec.

与外部API交互有时可能会很慢,并且在最坏的情况下,远程端无响应的服务器或网络中断或减速可能非常不可靠. Sidekiq是一种很好的方法,可以使您的应用程序(和您的最终用户)与远程API响应缓慢的可能性隔离开来.想象一下,由于某种原因,远程API运行缓慢,并且每个请求的平均响应时间减慢到2秒.在这种情况下,您只能处理5名工人的2.5雷亚尔/秒.如果流量超过最终用户可能会在应用上的任何页面响应之前开始等待很长时间,即使是那些没有进行远程API调用的人,因为所有的Web工作者可能都在等待缓慢的远程API回复.随着流量持续增加,您的用户将开始获得连接超时.

使用Sidekiq的想法是,您将等待外部API的时间与Web工作者分开.您基本上是从用户那里获取数据请求,将其传递给Sidekiq,然后立即向用户返回一个基本上说“我们正在处理您的请求”的响应.然后Sidekiq可以接收工作并提出外部请求.拥有数据后,它可以将数据保存回您的应用程序.然后,您可以使用Web套接字向用户发送数据已准备好的通知.甚至可以直接将数据推送给他们并相应地更新页面. (您也可以使用轮询让页面不断询问“它已准备就绪吗？”,但这很快就会非常低效.)

我希望这是有道理的.如果您有任何疑问,请告诉我.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!