我知道问题标题不是最好的。让我解释一下。
我做了TON的文本处理，将自然语言转换为xml。这些文本文件上传得相当快，并被扔进队列中。从那里将它们逐个拉到后台工作器中，后者调用我们的解析器（使用boost spirit）将文本转换为xml并将相关部分加载到我们的数据库中。
解析器一次可以执行大约100个这样的操作。我在后台工作者上有速率限制器，现在每隔一段时间只轮询我们的队列，所以它的执行速度不是很快。我现在不能抛出多个后台工作者因为我的http请求开始掉线 - 后台工作者和网络服务器存在于同一台机器上而我相信这是因为cpu使用率下降80-95％，虽然我们也可以使用更多的ram。
我需要更好地扩展它。你会怎么做呢？
回答几个问题：
我们使用亚马逊网络服务，所以购买便宜的额外硬件与产生一个新的亚马逊实例有点不同 - 也许有人做了一些自动生成负载量的实例代码？
我们确实有一个http服务器，只是将我们的文件填入队列中，因此它受影响的唯一原因是因为cpu忙着处理大量解析相关的东西
虽然我们没有在解析器本身中使用它，但我已经对后台工作者进行了限速
我还没有尝试过，但我过去曾经使用过它 - 我需要写下一些基准
解析器完全独立于Web服务器 - 我们将nginx / merb作为我们的Web /应用程序服务器，并将一个rake任务调用c ++作为我们的后台工作者 - 但它们确实存在于同一台机器上
答案 0 :(得分：8)
或许只是将后台工作人员置于较低的调度优先级（例如使用nice）会有所帮助。这意味着您的服务器可以在需要时处理请求，但是当它不忙时，您可以完全了解文本处理。
它可以为你提供比任意背叛后台工作者更多的好处。
答案 1 :(得分：4)
我会买几台便宜的电脑并对它们进行文字处理。正如杰夫在他的latest post中所说的那样，“总是试图首先从性能问题中解决问题，向它投掷更快的硬件。”
答案 2 :(得分：3)
我不确定我是否正确地关注了您的问题，但听起来您有一个HTTP引擎可以提供工作待处理队列。正确？后台线程正在接受这些队列请求并执行繁重的部分，正确吗？
因此，听起来后台进程是计算绑定的，前台进程本质上是I / O绑定的......或者至少受新工作提交速率的限制。
优化此类过程的最佳方法是将后台进程设置为低于前台进程的优先级。这可以确保后台进程能够继续完成工作。然后在进程之间设置队列深度，使其大小限制为您希望一次挂起的最大工作量。
答案 3 :(得分：1)
我做过的一件事就是将这些解析服务转移到云托管服务。
我已经将我的一些分布式服务（搜索引擎，群发电子邮件，错误记录）移到我的主要计算机上的云计算服务中，这对我们的主要Web服务器来说是一个很大的负担。
另外，云计算的可用性也越来越低，几乎无限扩展。
答案 4 :(得分：1)
我不明白为什么你会担心你的CPU达到100％。如果一个工作需要做，并且它不是IO绑定的，那么你的CPU 应为100％。
剩下的是：
如果不是，您需要更多的机器，更快的CPU或更高CPU效率的算法。前两个选项可能比第三个选项便宜 - 取决于您企业的规模！
听起来有。听起来您希望HTTP服务器具有响应能力，而解析器作业可以按照自己的进度完成（只要队列排空比填充更快）。正如其他人所指出的那样，好的告诉操作系统分配低优先级进程，在更高优先级的进程占用了他们需要的东西后，CPU周期“剩余”（尽管它不像那样黑白）。
答案 5 :(得分：0)
我假设您有多个线程，每个线程属于两个组之一
如果您认为B组限制了吞吐量，我会将其'线程设置为较低的优先级。如果有足够的工作，CPU仍将100％使用，但下载不会受到影响。
如果我的上述假设是正确的，那么你也应该使用多核和多CPU机器，因为你的性能应该可以用更多的CPU进行扩展。
答案 6 :(得分：0)
我将解析器放在自己的机器上。这样它就不会影响Web服务器。
如果您没有其他计算机的预算，那么使用虚拟化（如果您的Web服务器托管在Ubuntu或CentOS上，OpenVZ很酷），以限制解析器的CPU配额。
答案 7 :(得分：0)
如果您在处理中断请求时遇到问题，可以尝试增加CPU绑定任务的优点。然后是HTTP服务器的优点。基本上，尝试使用系统的调度程序，而不是将所有任务视为相等。
答案 8 :(得分：0)
我不知道您使用的操作系统，但大多数都具有指定线程/进程优先级的功能。只要解析器进程的优先级低于HTTP进程， 就可以了。
答案 9 :(得分：0)