全部：我正在寻求意见/指导/和设计理念。我的目标是找到一种精简但可靠的方法来从 HTTP POST 获取 XML 有效负载（这部分没有问题），对其进行解析，并异步生成一个相对寿命较长的进程。
生成的进程是 CPU 密集型进程，将持续大约三分钟。一开始我预计负载不会太大，但随着流量的增加，我很可能需要在服务器之间水平扩展负载。
我真的很喜欢 Celery/Django 堆栈的这种用途：它非常直观，并且拥有所有内置框架来完成我所需要的工作。我满怀热情地沿着这条路走下去，但很快我发现我的小型 512MB RAM 云服务器只有 100MB 的可用内存，而且我开始感觉到，一旦我的所有进程全速运行，我就会遇到麻烦。此外，它还有几个移动部件：RabbitMQ、MySQL、cerleryd、ligthttpd 和 django 容器。
我绝对可以增加服务器的大小，但我希望在该项目的早期阶段将成本降至最低。
作为替代方案，我正在考虑使用twisted 进行流程管理，并在需要时使用透视代理用于远程系统。但至少对我来说，虽然twisted很出色，但我觉得我沿着这条路做了很多事情：编写协议、回调管理、跟踪作业状态等。这里的好处非常明显 - 出色的性能，移动部件少得多，内存占用也更小（注意：我需要验证内存部分）。为此我非常偏向 Python——它比其他选择对我来说更有趣:)
我非常感谢对此的任何看法。我担心一开始就走上错误的轨道，并且稍后用生产流量重做这件事将会很痛苦。
-Matt
在我的系统上，以相当合理的默认值运行的 RabbitMQ 使用大约 2MB 的 RAM。 Celeryd用量稍多一些，但不要过量。
在我看来，与堆栈的其余部分相比，RabbitMQ 和 celery 的开销几乎可以忽略不计。如果您正在处理需要几分钟才能完成的作业，那么一旦流量增加，这些作业就会压垮您的 512MB 服务器，而不是 RabbitMQ。从 RabbitMQ 和 Celery 开始至少会让您很好地水平扩展这些工作，所以您肯定走在正确的轨道上。
当然，您可以在 Twisted 中编写自己的作业控制，但我认为它不会给您带来太大帮助。 Twisted 具有相当不错的性能，但我不认为它的性能优于 RabbitMQ 足以证明引入错误和架构限制的时间和潜力是合理的。大多数情况下，担心优化似乎是错误的。花点时间重写 RabbitMQ，努力将这三分钟的工作减少 20% 左右。或者只需每月额外花费 20 美元即可将容量翻倍。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
