爲多個線程提供單個HTTP請求

Angular 4應用程序向已部署在Websphere 8 Servlet容器中的Java spring MVC應用程序發送記錄列表。該列表然後插入到臨時表中。批量插入後，會進行過程調用以執行一些計算並返回結果。根據插入臨時表的列表大小，可能需要3000毫秒（N〜500），6000毫秒（N〜1000），50,000毫秒（N> 2000）之間的任意值。爲多個線程提供單個HTTP請求

我的輔助工具是創建數據塊並同時將它們發送到數據庫進行處理。線程（期貨）返回結果後，我會彙總它們並返回給客戶端。總而言之，我會將一個同步調用拆分爲多個異步進程（同時執行），並通過啓動HTTP調用的同一線程返回客戶端 - 進入我的控制器。

一切都會好的，我不會問這個問題，如果一個更有經驗的同事不會強烈反對這種方法。他的推理是使用這種方法由於線程中斷/超時/信號量等原因容易出現異常。您好，多線程應該避免在一個Web容器內，因爲它可以使Servlet容器崩潰，以防線程運行。他建議我們應該讓瀏覽器發送多個AJAX請求並聚合/呈現數據塊。

你能幫我理解哪種方法更好，爲什麼？

來源

2017-11-04 gumenimeda

聽起來更簡單，發送並行請求，然後編寫一堆服務器端代碼，但不是因爲將工作從servlet卸載到多個線程中存在任何固有問題。 – covener

在這種情況下，客戶端不僅要處理呈現數據，還要聚合。不會在客戶端增加更多的開銷嗎？我已經編寫了服務器端代碼（未經測試），但準備拋棄它，如果不是這樣做的話...... – gumenimeda

我不認爲這兩種方法都是客觀對錯或錯誤 – covener

我會說你的方法好得多。

由應用程序邏輯創建的線程不是應用程序容器線程，只受操作系統限制。雖然每個AJAX請求都使用來自應用程序容器的線程。因此，第二種方法會降低吞吐量並增加達到應用程序容器限制的可能性，而第一種方法則不能。性能也應該被考慮，因爲創建線程要比通過網絡發送請求便宜得多。此外，每個網絡請求使用額外的資源進行認證/授權/加密等。
它很難寫出正確的多線程代碼，並且容易出錯。但是，它不應該阻止你這樣做，因爲併發可以顯着提高你的性能。使用Future來處理中斷和超時非常簡單，您肯定不需要在這裏使用信號量。
將此邏輯暴露給客戶端看起來像破壞封裝。想象一下，你使用rest api，它迫使你發送多個請求，通過分割你的數據。我應該使用哪些塊大小？如何處理超時/中斷？我應該發送多少個請求？在這兩種方法中您都會遇到同樣的挑戰，但使用爲ExecutorService和Future等庫專門設計的應用程序要容易得多。

來源

2017-11-04 10:27:18

爲多個線程提供單個HTTP請求

回答

相關問題