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