Question

我正在努力巩固我对blocking对Web服务器请求意味着什么的理解，以及何时将请求转交给单独的工作人员（即sidekiq）是明智的。

请考虑以下示例：

使用Facebook登录

def sign_in
    response = Faraday.get("https://graph.facebook.com/me?fields=id,email&access_token=#{some_token}")
    user_info = JSON.parse(response.body)
    @user = User.find_by(uid: user_info["id"])
    ...
end

通过Google Firebase发送推送通知

def send_push_notification
  ...
  fcm = FCM.new(FCM_KEY)
  registration_ids = [recipient_token]
  resp = fcm.send(registration_ids, data: {body: notification_params[:body]})
  ...
end

在这两个示例中，对第三方服务的Web请求是同步的，并且可能代价高昂。直觉上，我会尝试使用单独的工作程序处理这些情况，因为它们阻止主应用程序。但是，我并不是100％确定阻止的含义。是否意味着当有100个用户尝试sign_in并且每个Faraday.get通话需要1秒时，所有用户都需要100秒才能登录？

Answer 1

这是否意味着当有100个用户尝试登录时和每个用户 Faraday.get通话需要1秒钟，所有通话需要100秒用户登录？

简单回答：是的。

在一个非常简单的场景中，第一个用户将等待1秒，第二个用户将等待2秒，依此类推。

如果您的应用程序/ Web服务器没有中止用户请求，则第100个用户将等待100秒。

更详细一点：依赖。

今天，现代Web应用程序（如Puma）在您的计算机上运行了多个进程工作程序。这意味着您的应用程序可以同时处理多个请求。

例如：如果您将Puma配置为使用2个工作程序，则您的应用程序将同时处理2个用户的请求。

因此，第一和第二用户将等待1秒，第三和第四用户将等待2秒，第99和第100用户将等待50秒。

由于每个Puma进程都消耗了大量的CPU和内存，因此无法拥有无限的工作者。这就是为什么非常有趣，有一个后台进程来发送这些推送通知。

在Sidekiq（例如）将工作委派给工人的成本非常低，因此您网站的用户不会受到处罚。

何时将工作从Web服务器移交给工作人员

1 个答案: