在工作中，我们不时要求这么长时间才能返回，因此前端（nginx）已经终止连接，因此用户将看不到输出（如果好或坏）。以编程方式停止请求
最糟糕的是，平衡器（haproxy）也会终止连接，然后假定服务器可以自由处理另一个请求，这意味着虽然服务器仍在处理旧请求，但新请求会进入并争取资源。
理想情况下，服务器一次只能处理一个请求，以便尽可能多地重用与ZEO数据库的连接线程，因此同时运行两个请求会使服务器更慢，然后我们的监控系统之一重新开始plone所有在一起，因为假人证明它发送超时。
因此给出了一些逻辑（可能重用我们已经使用的Products.LongRequestLogger）有没有办法告诉一个线程处理一个请求，停止这样做？
恕我直言，这是一个坏主意，手动中止请求。你以某种方式干扰冲突解决，这是恕我直言，不是一个很好的行为。
我正在运行一些大型plone网站，每天有200 - 400个作者发布/修改1000 - 3000个对象。通常情况下，负载会在一天内分摊，因此也会在合理的时间内处理更长的请求。例如，在晚上，等待多长时间（30秒至60秒）的请求表现良好。没有理由放弃他们。
在Plone中，我们有一些经典的长请求，比如重命名/移动一棵大树，更改权限，复制大量对象。然后，通常在目录的某处发生冲突，并在3次重试后中止事务。
通过中止长时间请求，您只需从Plone中删除一些功能。您可以考虑为重命名/移动/复制操作添加一个条件，以便它们不再存在，例如，如果容器中有1000个对象。
我试过/ DID至今：
使长请求短（哈哈，我现在只是简单地说，但很难实现:-)） - >例如结帐这个package's copy/move patch：它确实没有更长的时间做一个uncatalog /目录重命名和移动，而是更新只是必要的索引。我们用这个取得了很多成就。
队列：我用例如redis来排队和处理已知的长操作。当然，您需要事先了解哪些是潜在的长期需求，但我想您已经在您的环境中了解了这一点。您可以通过电子邮件与用户联系，或者在请求完成后通过某种类型的Flash消息。
保持目录尽可能小，一切委派到Solr/elasticsearch（删除SearchableText给你很多......）
硬件：我知道听起来很愚蠢，但这往往是速赢。尝试加载RAM中的至少所有目录对象。在快速的cpu/ssd（通用I/O）中投入几美元。这不是我喜欢的方式，但它发生，并在2016年它可以给你一些时间来解决长期请求问题。
未来：
Ehhh ......首先，我只是做了一个评论，但我超出字符限制;-)