gfo*_*ada 6 performance zope plone
在工作中,我们时不时地要求返回那么久,当它们完成时,前端(nginx)已经杀死了连接,因此用户将看不到输出(无论是好还是坏).
最糟糕的是,平衡器(haproxy)也将终止连接,然后假设服务器可以自由处理另一个请求,这意味着当服务器仍在处理旧请求时,新的请求会进入并争夺资源.
理想情况下,服务器应该一次只处理一个请求以尽可能多地重用与ZEO数据库的连接线程,因此同时运行两个请求会使服务器更慢,然后我们的一个监控系统正确地重新启动plone因为假人证明它发送时间.
所以给定一些逻辑(可能重用我们已经使用的Products.LongRequestLogger)有没有办法告诉线程处理请求停止这样做？
恕我直言，手动中止请求是一个坏主意。你以某种方式干扰了冲突的解决，恕我直言，这不是一个真正好的行为。
我正在运行一些大型克隆网站，有 200 - 400 位作者每天发布/修改 1000 - 3000 个对象。通常负载分布在一天中，因此较长的请求也将在合理的时间内得到处理。
例如，在晚上，长请求（30 秒 - 60 秒）表现良好。没有理由中止他们。
在 Plone 中，我们有一些经典的长请求，例如重命名/移动大树、更改权限、复制大量对象。然后通常会在目录中的某个地方发生冲突，并在 3 次重试后中止事务。
通过中止长请求，您只需从 Plone 中删除一些功能即可。您可以考虑向重命名/移动/复制操作添加一个条件，这样，如果容器中有 1000 个对象，它们就不再存在。
到目前为止我尝试过/做过的：
让长请求变短（哈哈，我现在只是简单地说，但很难实现:-)） --> 例如，检查这个包的复制/移动补丁：它不再为重命名和移动执行取消目录/目录，而是更新必要的索引。我们通过这一点取得了很多成就。
队列：例如，我使用 redis 来排队和处理已知的长操作。当然，您需要提前知道，这是一个潜在的长请求，但我想您在您的环境中已经知道这一点。如果请求完成，您可以通过电子邮件或某种即时消息联系用户。
保持目录尽可能小，将所有内容委托给 solr/elasticsearch （删除 SearchableText 会给你带来很多......）
硬件：我知道这听起来很愚蠢，但这通常是一个快速的胜利。尝试至少加载 RAM 中的所有目录对象。投资几美元购买快速 CPU/SSD（通用 I/O）。这不是我喜欢的方式，但它确实发生了，并且在 2016 年它可以给你一些时间来解决长请求问题。
未来：
呃……首先我只是发表了评论，但我超出了字符数限制;-)
| 归档时间： |
|
| 查看次数： |
108 次 |
| 最近记录： |