Мнение о синхронных запросах у веб-работников

Ответ 1

У меня нет веских фактов, но раз ты спрашивал мнения... :)

В Chrome есть серьезная проблема: слишком много веб-работников может вызвать тихий сбой (в соответствии с этим отчетом об ошибке ~ 60-100). Общая проблема заключается в том, что веб-работники ресурсоемки, по крайней мере, с v8.

Предполагая, что в конечном итоге вы сделаете несколько HTTP-вызовов, если вы делаете синхронные HTTP-вызовы в Web Worker:

• В некотором смысле вы торгуете асинхронными HTTP-вызовами для асинхронных веб-работников, которые будут только добавлять другого посредника в смесь, и вам все равно придется управлять вещами асинхронно.
• Если вы идете по более простому и более ресурсоемкому маршруту и используете только одного веб-работника, вы потратите много времени, ожидая его ответа.
• Если, с другой стороны, вы используете несколько веб-работников, вам, вероятно, потребуется отслеживать, какой из них свободен, какой занят и т.д., И в этом случае вы будете создавать собственный планировщик, а не использовать то, что приходит запеченный в браузере.
• Наконец, веб-работники стоят дорого (очевидно), и вам может понадобиться создать несколько веб-работников просто для того, чтобы они могли сидеть сложа руки и ждать завершения HTTP-вызова.

Я не считаю себя экспертом в этом вопросе, поэтому, пожалуйста, примите это во что бы то ни стало.

Обновление: добавление некоторых плюсов/минусов для различных сценариев.

Некоторые плюсы и минусы, которые приходят на ум при выборе между синхронными и асинхронными HTTP-вызовами при использовании веб-работника:

• Как правило, синхронные запросы будут легче писать и приводить к коду, которому легко следовать. Недостатком синхронных запросов является то, что они могут стимулировать написание длинных функций, которые должны быть выделены в отдельные, меньшие функции.
• Если вы делаете один вызов, нет никакой разницы во времени, которое требуется для завершения между двумя методами, а синхронный лучше, потому что он немного проще. Я говорю, что это немного проще, потому что один асинхронный вызов с одним слушателем обратного вызова действительно довольно прост.
• Если вы делаете несколько вызовов, которые должны происходить в определенной последовательности, например, загружая данные профиля пользователя и затем получая местную погоду на основе их адреса, синхронные вызовы будут лучше, потому что их будет легче писать и намного легче читать. Главное, что нужно прочитать, это то, что последовательные зависимости в вызовах будут четко очерчены выбором синхронных вызовов и их порядком в функции. Чем больше звонков, тем больше это будет иметь значение. Если звонков много, разница в сложности, вероятно, будет радикальной.
• Если вам нужно совершать несколько вызовов, которые не должны происходить в каком-либо определенном порядке, то асинхронные запросы лучше, потому что общий процесс, вероятно, будет на несколько порядков быстрее, чем с синхронными запросами. Чем больше звонков вы делаете или чем медленнее соединение, тем значительнее будет разница в общем затраченном времени; эта разница будет расти очень быстро (в геометрической прогрессии?). С точки зрения того, что кто-то читает код, я думаю, что использование синхронных запросов в этой ситуации будет несколько вводить в заблуждение, поскольку это предполагает, что вызовы имеют последовательный характер, хотя их нет. С точки зрения написания серии асинхронных запросов, которые не зависят друг от друга, это не должно быть слишком плохо, потому что вы просто устанавливаете счетчик, делаете все вызовы, увеличиваете счетчик в каждом из обратных вызовов, и вы закончите когда счетчик равен числу звонков, которые вы сделали.

Обновление: @rbrundritt делает очень интересное и актуальное наблюдение в комментарии к этому ответу:

Работая с веб-работниками, я обнаружил, что каждый из них, по-видимому, получает свой собственный лимит http. Браузеры ограничивают количество одновременных http-запросов до 8 или 12 в зависимости от браузера перед регулированием, что может стать узким местом, если у вас много запросов для обработки. Я обнаружил, что если я передаю свои запросы веб-работникам, каждый из них может выполнить от 8 до 12 одновременных запросов, прежде чем они начнут регулировать. Это может быть огромным преимуществом для некоторых приложений.

@rbrundritt

Ответ 2

Я просто хотел добавить примечание (это слишком долго для комментария), что ограничение в ~ 60 веб-работников, упомянутых в ответе @tiffon, похоже, больше не существует в Chromium. Я могу создать 500 рабочих в Chrome без ошибок/сбоев:

let workers = [];
for(let i = 0; i < 500; i++) {
  let worker = new Worker(URL.createObjectURL(new Blob(['console.log('cool${i}')'])));
  worker.postMessage({});
  workers.push(worker);
}
await new Promise(r => setTimeout(r, 15000));
for(let i = 0; i < workers.length; i++) {
  workers[i].terminate();
}

Хотя трудно представить ситуацию, когда сотни рабочих были бы уместны, учитывая, что число основных рабочих в настоящее время не превышает 64.