关于 Web Worker 中的同步请求的意见
我想知道您对此有何看法.是否建议在 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
相关文章