Частые опросы (POLLING) как способ обмена данных между клиентом и сервером. Доклад. Частые опросы (polling) как способ обмена данных между клиентом и сервером
 Скачать 21.13 Kb.
|
|
Частые опросы (POLLING) как способ обмена данных между клиентом и сервером Архитектура клиент-сервер – это концепция информационной сети, в которой основная часть ее ресурсов сосредоточена в серверах, обслуживающих своих клиентов. Рассматриваемая архитектура определяет два типа компонентов: серверы и клиенты. Сервер – это объект, предоставляющий сервис другим объектам сети по их запросам. Сервис – это процесс обслуживания клиентов. Процесс, который вызывает сервисную функцию с помощью определенных операций, называется клиентом. Им может быть программа или пользователь. Клиенты – это рабочие станции, которые используют ресурсы сервера и предоставляют удобные интерфейсы пользователя. Интерфейсы пользователя – это процедуры взаимодействия пользователя с системой или сетью. Частые опросы (polling) — это периодические запросы веб-страницы к серверу на предмет появления новых данных. В качестве реализации частых опросов используются разные подходы: использование объектов класса XMLHTTPRequest, элементы DOM script и пр. Традиционный способ получения данных от узлов сети. Этот способ характеризуется следующими особенностями: Механизм опроса. Запрос и получение информации от узлов сети в заданные интервалы времени. Интервалы времени чаще всего настраиваемые. Предоставляет информацию далекую от режима реального времени. Может случиться так, что событие уже произошло, но элемент сети еще не опрошен и до опроса еще остался большой промежуток времени. Требуется большая пропускная способность сети Самый простой способ получать новую информацию от сервера – периодический опрос. То есть, регулярные запросы на сервер вида: «Здравствуйте, я здесь, у вас есть какая-нибудь информация для меня?». Например, раз в 10 секунд. В ответ сервер, во-первых, помечает у себя, что клиент онлайн, а во-вторых, посылает весь пакет сообщений, накопившихся к данному моменту. Это работает, но есть и недостатки: Сообщения передаются с задержкой до 10 секунд (между запросами). Даже если сообщений нет, сервер «атакуется» запросами каждые 10 секунд, даже если пользователь переключился куда-нибудь или спит. С точки зрения производительности, это довольно большая нагрузка. Так что, если речь идёт об очень маленьком сервисе, подход может оказаться жизнеспособным, но в целом он нуждается в улучшении. Алгоритм работы: запрос → ответ Отправляем запрос на сервер. Получаем немедленный ответ. Повторяем это действие каждые N секунд/минут/etc., чтобы получать актуальные данные. Такой подход подразумевает большое количество запросов на сервер. Это создаёт определённую нагрузку на сетевой трафик. Ресурсы сервера нагружаются только во время запроса, но выгружаются как только был отдан ответ. Плюсы: Простота реализации. Причём, простота реализации тут достаточно условная. Клиентская часть – довольно проста, а вот сервер получает сразу большой поток запросов. Даже если клиент отошёл, оставив компьютер, на некоторое время – его браузер каждые 10 секунд будет «атаковать» сервер запросами. Готов ли сервер к такому? Минусы: - Лишний входящий трафик на сервер. При каждом запросе браузер передает множество заголовков и в ответ получает, кроме данных, также заголовки. Для некоторых приложений трафик заголовков может в 10 и более раз превосходить трафик реальных данных. - Задержки между событием и уведомлением. Сервер отсылает данные не тогда, когда они появились, а когда прилетит новый запрос. - Серверу приходится хранить события пока клиент не заберет их или пока они не устареют. Это можно перекрыть, добавив кеширующий слой типа Varnish (потребуется больше памяти). Советы и замечания касательно запросов: Делать polling каждую секунду — это излишество. Приложение всё равно будет казаться отзывчивым даже с 10 секундами задержки между циклами запросов. Чтобы уменьшить количество запросов к БД и увеличить скорость отклика от сервера, рассмотрите возможность использования memcached и храните там недоставленные сообщения. Конечно, вы сможете продолжать хранить сообщения в базе, однако кеширование в памяти может быть использовано для того, чтобы избежать запросов к БД каждые N секунд каждым юзером. Делайте таймаут для пользовательских чатов после X секунд неактивности, чтобы предотвратить polling к вашему серверу. Такой подход гарантирует, что пользователь не будет генерировать трафик, если вдруг просто оставит браузерную вкладку открытой в фоне. Можно добавить окно с запросом вроде «Вы ещё здесь? Нажмите, чтобы продолжить общение» для сессий, которые вот-вот истекут или прерывать цикл, если вкладка/окно вне зоны активного просмотра. Область применения: Периодические запросы отлично работают в тех случаях, когда сообщения приходят редко. При большом количестве частых сообщений (много пользователей — много диалогов) график приёма-отправки, превращается в «пилу». Каждое сообщение – это новый запрос, дополнительный трафик заголовков. В этих случаях используются другие способы получения данных, подразумевающие непрерывное соединение с сервером. |