我正在尝试与Google的Calendar API进行互动。到目前为止，我的测试显示插入单个事件的响应时间为5-10秒，我可能需要一次导出数千个事件[请勿询问]。这似乎有可能在不合理的时间内排除我的排队。 （此应用程序中95％的当前作业在<300ms内完成，因此这将使得更难以适当地分配资源。）
我目前正在此应用中使用Faraday来调用其他更快的Google API。法拉第维基建议使用Typhoeus进行并行HTTP请求;然而，截至2014年，使用Sidephq的Typhoeus被视为"a bad idea"。
Typhoeus还是个坏主意吗？如果是这样，在Sidekiq worker中生成N个线程，在每个线程中发出HTTP请求，然后等待所有线程重新加入是否合理？有没有其他方法可以完成这个极其I / O绑定的任务而不会让更多的工人遇到问题？我应该让我的经理增加我们的Sidekiq Enterprise支出吗？ ;）或者我应该把这些工作放在一个低优先级的队列中，并告诉我们的用户有荒谬的习惯，他们只需要等待？
在Sidekiq作业线程中使用线程是合理的。构建自己的线程基础结构是不合理的。您可以使用带有concurrent-ruby或parallel gems的可重用线程池，您可以使用一个线程安全的http客户端并允许并发请求等.HTTP.rb是一个很好的来自Tony Arcieri，但普通的旧网/ http将工作太：
https://github.com/httprb/http/wiki/Thread-Safety
请记住，有一些复杂性：可能会重试作业，如何处理HTTP客户端引发的错误？如果您不将这些请求与作业一对一地拆分，则可能需要跟踪每个请求或幂等性成为问题。
并且随时欢迎您增加您的Sidekiq Enterprise线程数。 :-D