Браузеры ограничивают скорость опроса AJAX? Каков предел?

Да, насколько мне известно, существует ограничение пула по умолчанию 10 и тайм-аут запроса по умолчанию 30 секунд на запрос, однако пределы тайм-аута и опроса можно контролировать, и разные браузеры реализуют разные ограничения!

зацените реализация Google.

и это реализация ловить ошибку тайм-аута!

вы можете найти специфику Firefox здесь!

особенности Internet Explorer контролируются из реестра Windows.

Смотрите также этот вопрос.

В основном, способ управления заключается не в изменении ограничений браузера, а в их соблюдении. Поэтому вы применяете метод, называемый дросселированием.

подумайте об этом как о создании очереди функций FIFO / priority. Структура очереди, которая принимает запросы xhr в качестве членов и применяет задержку между ними находится опрос Xhr. Например, я использую Jsonp для получения данных с узла.сервер js расположен на другом домене, и я, конечно, опрашиваю из-за ограничений браузера. В противном случае я получаю нулевой ответ от сервера, и это только из-за ограничений браузера.

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

Я буду еще более конкретным помочь вам. У меня есть страница на моем сайте, которая должна отображать представление для десятков или даже сотен статей. Вы проходите через них, используя прохладный горизонтальный слайдер.

текущее значение ползунка соответствует currrent 'страница'. Поскольку я показываю только 5 статей на странице, и я не могу точно загрузить тысячи статей "onload" без серьезных последствий для производительности, я загружаю статьи для текущей страницы. Я получаю их от MongoDB, отправляя междоменный запрос на Python скрипт.

скрипт должен возвращать массив из пяти объектов со всеми деталями, которые мне нужны для создания элементов DOM для "страницы". Однако, есть пара вопросов.

во-первых, слайдер работает очень быстро, так как это более или менее изменение значения. Даже если есть функция перетаскивания, события нажатия клавиш и т. д., фактическое изменение занимает миллисекунды. Однако, код слайдера выглядит примерно так:

goog.events.listen(slider, goog.events.EventType.CHANGE, function() {
    myProject.Articles.page(slider.getValue());
}

ползунок.метод getValue() возвращает int с текущим номером страницы, поэтому в основном мне нужно загрузить из:

currentPage * articlesPerPage to (currentPage * articlesPerPage + 1) - 1

но для того, чтобы загрузить, я делаю что-то вроде этого: У меня есть механизм хранения (подумайте об этом как о массиве):

• я проверяю, если содержание еще не там
• если это так, нет смысла делать другой запрос, поэтому продолжайте получать элементы DOM из массива с уже созданными элементами DOM на месте.

• Если это не так, тогда Мне нужно получить его, поэтому мне нужно отправить этот запрос, который я упоминал, который будет выглядеть примерно так(без учета ограничений браузера):

  JSONP в.отправить({'действие':'getMeSomeArticles','начало':пуск, длина: параметра itemsperpage должно, функцию(функцию обратного вызова){

  / / Теперь я просто быстро разбираю обратный вызов, чтобы убедиться, что он согласован // создание элементов DOM и заполнение хранилища на стороне клиента // и обновите представление для пользователя. }}

проблема происходит от скорости, с которой вы можете изменить этот слайдер. Поскольку каждое изменение предположительно запускает запрос (то же самое произойдет для обычных запросов Xhr), то вы в основном пересекаете ограничения всех браузеров, поэтому без дросселирования для большинства запросов не будет "обратного вызова". "обратный вызов" - это код JS, возвращаемый запросом JSONP (который является более удаленным включением скрипта, чем что-либо еще).

Так что я делаю, это push запрос в очередь приоритетов, а не опрос, как и сейчас, мне не нужно отправлять несколько одновременных запросов. Если очередь пуста, недавно добавленный элемент выполняется, и все довольны. Если это не так, то все незавершенные запросы отменяются и выполняется только последний.

Теперь в моем конкретном случае я выполняю двоичный поиск(0 (log n)), чтобы увидеть, если механизм хранения еще не имеет данных для предыдущих запросов, что говорит мне, если предыдущий запрос был завершен или нет. Если да, то он удален из очереди и текущего обрабатывается, в противном случае срабатывает новый. Так и так далее.

опять же, для рассмотрения скорости и дерьма браузер хочет-бес, такие как Internet Explorer, я делаю описанную выше процедуру примерно на 3-4 шага вперед. Поэтому я предварительно загружаю 20 страниц вперед, пока все не станет механизмом хранения на стороне клиента. Таким образом, все ограничения успешно решать.

время перезарядки покрыто минимальным временем, которое потребуется, чтобы проскользнуть через 20 страниц и дроссельная заслонка гарантирует, что в любой момент времени не более 1 активных запросов(с обратной совместимостью до Internet Explorer 5).

причина, по которой я написал все это, чтобы дать вам пример, пытаясь сказать, что вы не можете всегда применять задержку непосредственно из структуры FIFO, так как ваши вызовы могут превратиться в то, что видит пользователь, и вы точно не хотите, чтобы пользователь ждал 10-15 секунд для одной страницы, чтобы оказывать.

кроме того, всегда минимизируйте опрос и необходимость опроса(одновременно запускаются события Ajax, так как не все браузеры на самом деле делают с ними хорошие вещи). Например, вместо того, чтобы отправлять один запрос на получение контента и отправлять другой для отслеживания этого контента в метриках приложения, выполните как можно больше задач на уровне сервера!

конечно, вы, вероятно, хотите правильно отслеживать свои ошибки, поэтому ваш объект Xhr от ваша библиотека выбора реализовать обработку ошибок для ajax и потому, что вы удивительный разработчик вы хотите использовать их.

так сказать, у вас есть блок try-catch на месте Сценарий это: Вызов Ajax завершен, и он должен вернуть JSON, но вызов каким-то образом не удался. Тем не менее, вы пытаетесь проанализировать JSON и сделать все, что вам нужно сделать с ним. так что

function onAjaxSuccess (ajaxResponse) {
    try {
        var yourObj = JSON.parse(ajaxRespose);
    } catch (err) {
    // Now I've actually seen this on a number of occasions, to log that an error occur
    // a lot of developers will attempt to send yet another ajax request to log the
    // failure of the previous one.
    // for these reasons, workers exist.
    myProject.worker.message('preferrably a pre-determined error code should go here');
    // Then only the worker should again throttle and poll the ajax requests that log the
    //specific error. 
};

};

хотя я видел различные реализации, которые пытаются запустить столько запросов Xhr на в то же время, как они могут, пока они не столкнутся с ограничениями браузера, а затем сделать довольно хорошую работу по остановке тех, которые не уволили в ожидании браузера "перезарядка", что я могу посоветовать вам подумать о следующем:

• насколько важна скорость для вашего приложения?
• насколько масштабируемым и насколько интенсивным будет ввод-вывод?

Если ответ на первый "очень" и на последний "OMFG modern technology", попробуйте оптимизировать ваш код и архитектура столько, сколько вы можете, так что вам никогда не нужно отправлять 10 одновременных запросов Xhr. Кроме того, для крупномасштабных приложений многопоточные процессы. Способ JavaScript для достижения этого-использование рабочих. Или вы можете позвонить в Совет ECMA, сказать им, чтобы сделать это по умолчанию, а затем опубликовать его здесь, чтобы остальные из нас JS devs могли наслаждаться родной многопоточностью в JS:)(как dafuq они не думали об этом?!?!)

нет, браузер никоим образом не влияет на опрос. Я думаю, что на этой странице подразумевалась та же политика origin - вы можете получить доступ только к тому же хосту и Порту, что и Ваша исходная страница.

единственным известным ограничением для самих соединений является то, что вы обычно можете иметь только от двух до четырех одновременных соединений с одним и тем же хостом.

Я написал несколько приложений с длинным опросом, некоторые с бэкэндом C++ с моим собственным веб-сервером и один с бэкэндом PHP с Apache2.

мой длинный тайм-аут опроса 4..10 сек. Когда что-то происходит, или 4..10 сек проходит, мой сервер возвращает пустой ответ. Затем клиент немедленно запускает еще один запрос AJAX. Я обнаружил, что некоторые браузеры зависают при запуске AJAX-вызова из предыдущего обработчика AJAX, поэтому я использую setTimeout() с небольшим значением для запуска следующего AJAX запрос.

когда что-то происходит на стороне клиента, который должен быть отправлен на сервер, я использую для этого другой запрос AJAX, но это одностороннее: сервер не отправляет никакого ответа, и клиент ничего не обрабатывает. Результат операции (если таковой имеется) будет получен при длительном опросе. Для этого требуется Макс. 2 подключение к серверу, которое поддерживают все браузеры.

имейте в виду, что если есть клиент 500, это означает поток веб-сервера 500 на стороне сервера, который будут двигаться вместе, возникающие пики нагрузки, потому что, когда что-то происходит, сервер должен сообщить об этом одновременно для каждого клиента, клиенты будут обрабатывать его почти в то же время долго, они начнут следующий длинный запрос в то же время, и с тех пор тайм-аут истечет также в то же время, и последующие тоже. Вы можете обмануть с таймаутом rnd, скажем, 4 rnd (0..4), но это бесполезно, если что-нибудь случится, они снова" синхронизируются", все запросы должны обслуживаться одновременно, когда происходит что-то заслуживающее внимания.

я протестировал его через маршрутизатор, и он работает. Я предполагаю, что роутеры уважают 4..10 лаг, это вокруг скорости медленного webapge (далеко, далеко), который ни один маршрутизатор не думает, что он должен быть отменен.

моя работа PHP-это совместная электронная таблица, она выглядит потрясающе, когда вы нажимаете enter, и материал обновляется одновременно в нескольких браузерах. Получайте удовольствие!

нет ограничений для запросов ajax. Однако он будет на том же хосте и Порту.

сервер не может ограничить запрос от машины на основе его настройки.

например. Сервер может установить так, что если есть более чем несколько запросов от одной машины в течение указанного времени, он отклонит запрос.

после небольшой ошибки в коде javascript, бесконечный цикл был сделан ведьма каждый шаг вызова 2 ajax запросов. В firebug я мог видеть все больше и больше запросов, пока firefox не начал замедляться, не реагировать и, наконец, сбой.

Итак, да, есть "предел";)