【发布时间】：2012-02-11 02:56:24
【问题描述】：
我们的应用有一个搜索任务，运行时间不到 30 秒。我们使用delayed_job 将任务移至后台，效果很好。为了处理更多的搜索请求，我们开放了60个delayed_job worker，当更多worker同时工作时问题就来了。
如果我向服务器发送一个请求，完成这项工作大约需要 30 秒；然后我尝试向服务器发送 10 个请求，每个作业需要 >3 分钟才能完成......如果我尝试同时向服务器发送 30 个请求，每个作业需要 26 分钟才能完成...... .....我的天...
我们的搜索任务可以分为两部分。首先，使用线程（http://www.tutorialspoint.com/ruby/ruby_multithreading.htm）向第三方服务器发送 10-20 个 API 请求，并等待响应，大约需要 15 秒才能完成。其次，我们处理响应数据，搜索本地mySQL DB，进行一些循环和计算，最后将结果保存到文件系统中（文件位置是使用NFS的共享空间），大约需要10秒才能完成。
我使用 Linux 'top' 命令，发现当 1 个作业运行时，有时会占用 100% 的 cpu 功率。当我同时运行 30 个作业时，每个作业占用
目前我不知道如何提高速度，使其支持更多用户，速度约为 30 秒...
我们使用的是 Rails 3.0.x、Ruby 1.9.2p290（真正的线程？），一个运行 4 个虚拟机（DB、Ngnix、Ruby/Unicorn、Ruby/delayed_job）的服务器。
我现在的想法是： - 真正的线程（如何测试我们是否是？） - jRuby（在这种情况下有帮助吗？） - 网络 IO（服务器管理员说不太可能） - 文件系统/NFS IO（服务器管理员说不可能）
任何有类似经验的人可以给我一些想法，所以我可以深入研究这个问题？非常感谢！
【问题讨论】：
-
不是开60个delayed_job工人，而是开5个左右。您可以很容易地找到最佳数量——计算每份工作的时间，并且为您提供最低限度的工人数量就是您想要的。每 3 分钟 10 次优于每 30 秒 1 次，但低于每 26 分钟 30 次。 （并尝试弄清楚为什么需要这么多 CPU 时间。）
-
我想补充一下 David 的建议，您应该 profile your application 发现为什么您的搜索如此密集。 OProfile 只是一个建议——您可能会通过询问您的 SQL 系统到
EXPLAIN其查询并添加索引、删除锁定、添加事务、制作更小的事务等来找到更多启发性的数据。谁知道呢。不过，OProfile 是一种很好的机制，可以发现什么在消耗您的 CPU，并有望为您提供所需的信息，以最少的努力实现最大的改进。 -
谢谢！我有更多关于硬件的信息：~2.4ghz，总共 8 个 CPU（xeon x2）和 HT，所以 VM 可以有 16 个核心
-
我在编码中放了一些带时间的日志，用3rd方API请求日志显示：文件IO没有问题（几乎是实例）；使用线程的第 3 方 API 调用正在工作（同时发送）；第三方API响应时间正常...参考我的问题，当10个请求时，第一部分需要~90秒，20秒等待API响应是正常的，但其他60秒是插件处理响应，即萨文 (savonrb.com);第二部分使用〜100秒...
-
谢谢萨诺德。我们已经使用 query_viewer 优化了 SQL，并且我们的 memcached 命中率 >90%。现在IMO，看起来是编码，包括我们的编码，Rails本身和插件（如savonrb.com），当多进程同时运行时运行非常慢
标签： ruby-on-rails multithreading virtual-machine delayed-job cpu-usage