performance - 以编程方式停止请求

Question

在工作中，我们时不时地请求这么长时间在他们完成时返回它，前端(nginx)已经终止了连接，所以用户将看不到输出(无论是好还是坏)。

最糟糕的是，平衡器(haproxy)也会终止连接，然后假设服务器可以自由处理另一个请求，这意味着当服务器仍在处理旧请求时，一个新请求会进来并争夺资源。

理想情况下，服务器一次应该只处理一个请求，以尽可能多地重用与 ZEO 数据库的连接线程，因此同时运行两个请求会使服务器变得更慢，然后我们的一个监控系统正确地重新启动 plone 一起因为假人证明它发送超时。

所以给定一些逻辑(也许重用我们已经使用的 Products.LongRequestLogger)，有没有办法告诉处理请求的线程停止执行它？

Answer 1

恕我直言，手动中止请求是个坏主意。您以某种方式干扰了冲突解决，恕我直言，这不是一个非常好的行为。

我正在运行一些大型 Plone 网站，每天有 200 到 400 位作者发布/修改 1000 到 3000 个对象。通常负载分散在一天中，因此更长的请求也将在合理的时间内得到处理。

例如在晚上，长请求(30s - 60s)表现良好。没有理由中止他们。

在 Plone 中，我们有一些经典的长请求，例如重命名/移动大树、更改权限、复制大量对象。然后通常冲突发生在目录中的某个地方，并在 3 次重试后中止事务。

通过中止长请求，您只需从 Plone 中删除一些功能。您可以考虑为重命名/移动/复制操作添加条件，以便它们不再存在，例如，如果容器中有 1000 个对象。

到目前为止我尝试/做了什么:

使长请求更短(哈哈，我现在只是说但很难实现:-))--> 例如检查这个 package's copy/move patch :它不再为重命名和移动执行取消目录/目录，而是只更新必要的索引。我们在这方面取得了很多成就。

队列:我使用例如 redis 来排队和处理已知的长 Action 。当然你需要提前知道，这是一个潜在的长请求，但我想你已经在你的环境中知道了这一点。如果请求完成，您可以通过电子邮件或某种类型的闪存消息与用户联系。

保持目录尽可能小，将所有内容委托(delegate)给 solr/elasticsearch(删除 SearchableText 会给你很多...)

硬件:我知道这听起来很傻，但这通常是一种速赢。尝试至少加载 RAM 中的所有目录对象。在快速 cpu/ssd(通用 I/O)上投资几美元。这不是我喜欢的方式，但它发生了，在 2016 年它可以给你一些时间来解决长请求问题。

future :

您可能见过 Jim Fulton "The ZODB" talk at the ploneconf 2016 .如果您可以在 zeoclient 上处理冲突解决方案，并且您只获得了对象而不是状态，则可以实现更好的冲突解决方案。

嗯...首先我只发表了评论，但我超出了字符数限制 ;-)