問題描述

我想知道您對此有何看法.是否建議在 web worker 中使用同步請求(XMLHttpRequest)?我能找到什么問題?

I want to know what do you think about this. Is recommended to use synchronous requests (XMLHttpRequest) in a web worker? What problems can I find?

我一直在我的應用程序中對此進行測試，但沒有發現任何問題.但由于 jQuery 和 AJAX 的舊經驗，我害怕這種同步行為.我的應用程序從數據庫中的多個表中獲取大量數據，這需要時間.對于從表中檢索到的每一束數據，我需要立即處理它，以免過多地延遲整個事情.同時，用戶正在與瀏覽器交互，所以它可以被阻止，我認為網絡工作者可以正常工作.你認為這是一個好的解決方案嗎?還是我應該嘗試異步請求?

I have been testing this in my app and I haven't find any trouble. But I'm afraid of this synchronus behaviour because of old experiences with jQuery and AJAX. My app gets a big amount of data from several tables in a database, and this requires a time. For each bunch of data retrieved from a table, I need to instantly process it to not delay the whole thing too much. Meanwhile, the user is interacting with the browser, so it can be blocked, and I thought that web workers would work fine. Do you thing that this is a good solution? Or should I try with asynchronus requests?

謝謝.

推薦答案

我沒有確鑿的事實，但既然你征求意見... :)

I don't have hard facts, but since you asked for opinions... :)

Chrome 中有一個明顯的問題:Web Worker 過多會導致無聲崩潰(根據 這個錯誤報告).一般的問題是 Web Workers 是資源密集型的，至少在 v8 中是這樣.

There is a telling issue in Chrome: Too many Web Workers can cause a silent crash (caps ~60-100, according to this bug report). The general problem is Web Workers are resource intensive, at least with v8.

假設您最終要進行多個 HTTP 調用，如果您在 Web Worker 中進行同步 HTTP 調用:

Assuming you're going to end up making multiple HTTP calls, if you're doing synchronous HTTP calls in a Web Worker:

• 從某種意義上說，您正在為異步 Web Worker 交易異步 HTTP 調用，這只會在混合中添加另一個中介，您仍然需要異步管理事物.
• 如果您采用更簡單、資源效率更高的路線并且只使用一個 Web Worker，您將花費大量時間等待它給您響應.
• 另一方面，如果您使用多個 Web Worker，您可能需要跟蹤哪個是空閑的，哪個是忙碌的，等等，在這種情況下，您將創建一個自制的調度程序而不是使用瀏覽器內置的內容.
• 最后，Web Worker 很昂貴(顯然)，您最終可能會創建多個 Web Worker，這樣他們就可以坐下來等待 HTTP 調用完成.

我不認為自己是這方面的專家，所以請接受它的價值.

I do not consider myself an expert on the matter, so please take this for what it's worth.

更新:為各種場景添加一些優點/缺點.

Update: Adding some pros / cons for various scenarios.

在使用 Web Worker 進行同步和異步 HTTP 調用之間進行選擇時想到的一些優點/缺點:

Some pros / cons that come to mind when choosing between making synchronous and asynchronous HTTP calls when using a Web Worker:

• 通常，同步請求會更容易編寫，并且會生成易于遵循的代碼.同步請求的一個缺點是它們可能會鼓勵編寫長函數，這些函數應該被分割成單獨的更小的函數.
• 如果您只進行一次調用，則兩種方法完成所需的時間沒有區別，同步更好，因為它更簡單一些.我說它只是簡單一點，因為帶有一個回調偵聽器的單個異步調用確實相當簡單.
• 如果您要以特定順序進行多次調用，例如加載用戶的個人資料數據，然后根據他們的地址獲取當地天氣，那么同步調用會更好，因為它更容易編寫并且更容易閱讀.閱讀它的主要內容是調用中的順序依賴關系將通過選擇同步進行調用及其在函數中的順序來清楚地概述.呼叫越多，這就越重要.如果調用很多，復雜度上的差異可能會很大.
• 如果您必須進行不需要以任何特定順序發生的多次調用，那么異步請求會更好，因為整個過程可能比同步請求快幾個數量級.您撥打的電話越多或連接速度越慢，總經過時間的差異就越大；這種差異會迅速增長(呈指數增長?).從閱讀代碼的人的角度來看，我認為在這種情況下使用同步請求會有點誤導，因為它表明調用具有順序性，即使沒有.從編寫一系列不依賴于彼此的異步請求的角度來看，這應該不會太糟糕，因為您只需設置一個計數器，進行所有調用，在每個回調中遞增計數器，您就完成了當計數器等于您撥打的電話次數時.

• Generally, synchronous requests will be easier to write and will result in code that is easy to follow. A downside of synchronous requests is they might encourage writing long functions that should be carved out into separate, smaller functions.
• If you're making a single call, there is no difference in the time it takes to finish between the two methods and synchronous is better because it's a bit simpler. I say it's only a bit simpler because a single asynch call with one callback listener is really rather simple.
• If you're making multiple calls that have to happen in a specific sequence, like loading a user's profile data and then getting the local weather based on their address, synchronous calls will be better because it will be easier to write and a lot easier to read. The main thing about reading it is the sequential dependencies in the calls will be clearly outlined by the choice of making the calls synchronously and their order in the function. The more calls there are, the more this will matter. If there are many calls, the difference in complexity is likely to be drastic.
• If you have to make multiple calls that do not need to happen in any specific order, then asynchronous requests are better because the overall process is likely to be orders of magnitude faster than with synchronous requests. The more calls you're making or the slower the connection, the more significant the difference in total elapsed time will be; this difference will grow very quickly (exponentially?). From the perspective of someone reading the code, I think using synchronous requests, in this situation, would be somewhat misleading as it would suggest there is a sequential nature to the calls even though there is not. From the perspective of writing a series of asynch requests that are not dependent on each other, it shouldn't be too bad because you just setup a counter, make all the calls, increment the counter in each of the callbacks and you're finished when the counter equals the number of calls you made.

更新:@rbrundritt 制作了一個非常有趣且相關的 對此答案的評論中的觀察:

Update: @rbrundritt makes a very interesting and relevant observation in a comment on this answer:

我發現與網絡工作者一起工作的一件事是，他們似乎每個人都獲得了自己的 http 限制.瀏覽器將并發 http 請求的數量限制在 8 或 12 左右，具體取決于限制之前的瀏覽器，如果您有大量請求要處理，這可能是一個瓶頸.我發現如果我通過我的請求網絡工作者，每個人可以在開始節流之前執行 8 到 12 個并發請求.這對某些應用來說可能是一個巨大的好處.

One thing I found working with web workers is that they appear to each gain their own http limit. Browsers limit the number of concurrent http requests to around 8 or 12 depending on the browser before throttling, which can be a bottle neck if you have a lot of requests to process. I've found that if I pass my requests web workers, each can do 8 to 12 concurrent requests before they start throttling. This can be a huge benefit for some apps.

@rbrundritt

這篇關于關于 Web Worker 中的同步請求的意見的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！