Ваш вопрос поднимает возможность трех разных методов:
- Веб-сокеты (Фэй, Iodine, EM-Websockets или любой другой веб-сокет решение, которое вы предпочитаете).
- Короткий опрос (уведомления в стиле «вытягивания» на основе клиента).
- Долгий опрос (клиент и сервер пытаются установить постоянное соединение - технология до веб-сокетов).
Хотя веб-сокеты кажутся наиболее масштабируемым и естественным решением для push-уведомлений, это, как и большинство вещей, зависит от конкретного приложения. Вам нужно будет учитывать свои ресурсы и свои потребности и сбалансировать их наилучшим образом.
Веб-сокеты против короткого опроса имеют свою цену. В то время как Short-Polling легче реализовать, веб-сокеты позволяют реально продвигать, а их дизайн предназначен для экономии веб-ресурсов и ресурсов сервера.
Что касается Websockets vs. Long polling, то ответ довольно прост — Websockets будут эффективнее.
Длительный опрос эмулирует постоянное соединение, блокируя HTTP-запрос, отправленный браузером, до тех пор, пока сервер не получит данные для ответа. Это может заблокировать весь сервер, если его параллелизм неэффективен, и, очевидно, заблокирует поток, отвечающий за ответ на запрос (сколько потоков находится в пуле потоков вашего сервера? 8? 24?).
Напротив, веб-сокеты ЯВЛЯЮТСЯ постоянными соединениями, которые не блокируют, а интегрируются с сервером. Это гораздо более элегантное и экономичное решение.
Вы можете найти больше информации о длительном и коротком опросе здесь:
В примере:
Предположим, вы ожидаете, что 5000 активных клиентов будут подключаться к вашему веб-сайту в любой момент (если каждый клиент тратит на подключение 30 минут в день, это означает, что общее количество клиентов составляет около 240 000, без учета пиков и спадов времени использования).
Теперь давайте сравним ресурсы только для push/update части приложения:
Короткий опрос: если каждый клиент отправляет запрос на обновление каждые 2 секунды (не быстро, но и не слишком медленно, в зависимости от того, что вам нужно), вам нужно обрабатывать 2500 запросов в секунду только для ответа на запросы на запрос на обновление. . Каждый запрос повлияет на память, производительность и скорость отклика вашего приложения.
Долгий опрос: у вас будет 5000 подключений, заблокированных и ожидающих ответа. Это 5000 задач, каждая из которых, вероятно, использует поток... даже если вам удастся циклически выполнять задачи, используя некоторый асинхронный ответ и пул потоков (что очень сложно для стоечных серверов), вы будете потреблять ресурсы ЦП и памяти в ожидании обновления. Кроме того, каждое обновление потребует от вас обновления 5000 подключений (или, если вам повезет, функция HTTP/1.1 keep-alive избавит вас от этого неудобства). Эти заблокированные соединения будут влиять на скорость отклика и производительность вашего приложения, используя циклы ЦП и отвлекая внимание от реальных запросов. Это может быть (а может и нет) лучше, чем пытаться ответить на 2500 запросов в секунду... но не очень эффективно. Отправка данных происходит мгновенно.
Веб-сокеты: к серверу IO-реактору будет добавлено 5000 подключений. . Обратные вызовы веб-сокета будут вызываться всякий раз, когда происходит какая-либо активность (которая может никогда не произойти), и ни один из ваших потоков не заблокирован. Обновления, отправляемые с использованием соединений через веб-сокеты, не приводят к закрытию соединений, поэтому нет необходимости возобновлять соединения при каждом обновлении. Отправка данных происходит мгновенно.
заключение:
По замыслу, если у вас есть собственный сервер, вы должны иметь возможность обслуживать гораздо больше клиентов с помощью веб-сокетов, чем с помощью коротких или длинных опросов.
Тем не мение:
Веб-сокеты (как и длинные опросы) кодировать сложнее, чем короткие опросы (они используют очень ценный ресурс — часы кодирования человека);
некоторые службы хостинга (например, Heroku) будут ограничивать количество клиентов веб-сокетов, делая математику менее определенной... с другой стороны, ограничения параллелизма (запрос/сек) для тех же самых служб, вероятно, окажутся в пользу веб-сокетов.
person
Myst
schedule
01.09.2015
