在工作中，我們不時要求這麼長時間才能返回，因此前端（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 ......首先，我只是做了一個評論，但我超出字符限制;-)