Мнение о синхронных запросах в Web workers
Я хочу знать, что вы думаете об этом. Рекомендуется ли использовать синхронные запросы (XMLHttpRequest) в веб-работнике? Какие проблемы я могу найти?
Я тестировал это в своем приложении, и я не нашел никаких проблем. Но я боюсь этого синхронного поведения Из-за старого опыта работы с jQuery и AJAX. Мое приложение получает большой объем данных из нескольких таблиц в базе данных, а это требует времени. Для каждой группы данных, извлеченных из таблицы, мне нужно немедленно обработайте его, чтобы не слишком затягивать. Между тем, пользователь взаимодействует с браузером, поэтому его можно заблокировать, и я подумал, что веб-работники будут работать нормально. Вы считаете, что это хорошее решение? Или я должен попробовать с запросами asynchronus?
спасибо.
1 ответов
У меня нет твердых фактов, но так как вы спросили мнения... :)
в Chrome есть проблема: слишком много веб-работников могут вызвать тихий сбой (caps ~60-100, согласно этот отчет об ошибке). Общая проблема заключается в том, что веб-работники ресурсоемки, по крайней мере, с v8.
предполагая, что вы собираетесь в конечном итоге сделать несколько HTTP-вызовов, если вы делаете синхронные HTTP-вызовы в веб-работнике:
- в некотором смысле, вы торгуете асинхронные HTTP-вызовы для асинхронных веб-работников, которые будут добавлять только другого посредника в микс, и вам все равно придется управлять вещами асинхронно.
- если вы идете по более простому и ресурсоэффективному маршруту и используете только одного веб-работника, вы потратите много времени на ожидание его ответов.
- если, с другой стороны, вы используете несколько веб-работников, вам, вероятно, нужно будет отслеживать, какой из них свободен, какой занят и т. д. в таком случае вы будете создавать домашний планировщик вместо того, чтобы использовать то, что запечено в браузере.
- наконец, веб-работники дороги (по-видимому), и вы можете в конечном итоге создать несколько веб-работников, чтобы они могли сидеть и ждать завершения HTTP-вызова.
Я не считаю себя экспертом в этом вопросе, поэтому, пожалуйста, возьмите это за то, что это стоит.
Update: добавление некоторых плюсов / минусов для различных сценариев.
одни плюсы / минусы, которые приходят на ум при выборе между синхронными и асинхронными HTTP-вызовами при использовании веб-работника:
- как правило, синхронные запросы будет легче писать и приведет к коду, который легко следовать. Недостатком синхронных запросов является то, что они могут стимулировать написание длинных функций, которые должны быть разделены на отдельные, меньшие функции.
- если вы делаете один звонок, нет никакой разницы во времени, которое требуется, чтобы закончить между двумя методами и синхронным лучше, потому что это немного проще. Я говорю, что это только немного проще, потому что один вызов asynch с одним слушателем обратного вызова действительно довольно прост.
- если вы делаете несколько вызовов, которые должны произойти в определенной последовательности, например, загрузка данных профиля пользователя, а затем получение локальной погоды на основе их адреса, синхронные вызовы будут лучше, потому что будет легче писать и намного легче читать. Главное в чтении именно последовательные зависимости в вызовах будут четко очерчены выбором выполнения вызовов синхронно и их порядком в функции. Чем больше звонков, тем больше это будет иметь значение. Если есть много вызовов, разница в сложности, вероятно, будет резкой.
- Если вам нужно сделать несколько вызовов, которые не должны происходить в каком-либо определенном порядке, то асинхронные запросы лучше, потому что общий процесс, вероятно, будет на порядки быстрее чем с синхронными запросами. Чем больше вызовов вы делаете или чем медленнее соединение, тем более существенной будет разница в общем затраченном времени; эта разница будет расти очень быстро (экспоненциально?). С точки зрения того, кто читает код, я думаю, что использование синхронных запросов в этой ситуации будет несколько вводит в заблуждение, поскольку это предполагает, что существует последовательный характер вызовов, даже если его нет. С точки зрения написания серии asynch запросы, которые не зависят друг от друга, это не должно быть слишком плохо, потому что вы просто настроить счетчик, сделать все вызовы, увеличить счетчик в каждом из обратных вызовов, и вы закончите, когда счетчик равен количеству вызовов вы сделали.
обновление: @rbrundritt делает очень интересным и актуальным замечание в комментарий на этот ответ:
одна вещь, которую я нашел, работая с веб-работниками, заключается в том, что они каждый получает свой собственный предел http. Браузеры ограничивают количество одновременных http-запросов примерно до 8 или 12 в зависимости от браузера перед дросселированием, которое может быть горлышком бутылки, если у вас есть много запросов для обработки. Я обнаружил, что если я передаю свои запросы веб-работникам, каждый может выполнять от 8 до 12 одновременных запросов, прежде чем они начнут дросселировать. Это может быть огромным преимуществом для некоторых приложений.