Опрос Ajax против SSE (производительность на стороне сервера) - PullRequest
0 голосов
/ 29 апреля 2019

Мне любопытно, есть ли какой-то тип стандартного ограничения на то, когда лучше использовать Ajax Polling вместо SSE, с точки зрения серверной стороны.

  • 1 запрос каждую секунду: я уверен, что лучше SSE
  • 1 запрос в минуту: я уверен, что лучше Ajax

А как насчет 1 запроса каждые 5 секунд? Как мы можем рассчитать, где находится предельная частота для Ajax или SSE?

Ответы [ 2 ]

2 голосов
/ 30 апреля 2019

Для Ajax всегда лучше 1 запрос в минуту, так что предположение ошибочно с самого начала. Любой частый опрос почти всегда является дорогостоящим выбором. Из нашего предыдущего разговора в комментариях к другому вопросу видно, что вы начинаете с убеждения, что открытый TCP-сокет (будь то соединение SSE или соединение webSocket) каким-то образом дорого обходится производительности сервера. Свободное TCP-соединение требует нулевого ЦП (возможно, каждый раз в течение долгого времени может быть отправлено подтверждение активности, но, кроме этого, незанятый сокет не использует ЦП). Он использует немного серверной памяти для обработки дескриптора сокета, но сильно настроенный сервер может иметь одновременно 1 000 000 открытых сокетов. Итак, ваша загрузка ЦП будет больше зависеть от того, сколько соединений устанавливается и что они просят сервер делать каждый раз, когда они устанавливаются, чем от того, сколько существует открытых (и в основном незанятых) соединений.

Помните, что каждое http-соединение должно создавать TCP-сокет (который является обходом между клиентом / сервером), затем отправлять http-запрос, затем получать http-ответ, затем закрывать сокет. Это большое количество данных, которые нужно делать каждую минуту. Если соединение установлено по протоколу https, для установления соединения требуется еще больше работы и обходных путей из-за уровня шифрования и сертификации конечных точек. Таким образом, выполнение всего этого каждую минуту для сотен тысяч клиентов кажется огромной тратой ресурсов и пропускной способности, когда вы можете создать одно соединение SSE, а клиент просто прослушивает поток данных с сервера через это соединение.

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

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

Преимущество # 1 для push-сервера (независимо от того, реализуете ли вы его с помощью SSE или webSocket) состоит в том, что сервер должен что-то делать с клиентом только при наличии действительно соответствующих данных для отправки этому конкретному клиенту. Все остальное время сокет просто бездействует (возможно, иногда на длительный промежуток времени, отправляя сигнал активности).

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

Как мы можем рассчитать, где находится предельная частота для Ajax или SSE?

Это довольно сложный процесс. Множество переменных в конкретном сценарии должны быть определены. Это не так просто, как просто запросы / сек. Затем вы должны решить, что вы пытаетесь измерить или оценить и в каком масштабе? «Производительность сервера» - это единственное, что вы упоминаете, но оно должно быть полностью определено, и различные факторы, такие как загрузка процессора и использование памяти, должны быть взвешены на то, что вы измеряете или вычисляете. Затем вам может даже понадобиться запустить некоторые тестовые наборы, если вычисления не дают очевидного ответа или если решение настолько критично, что вы хотите проверить свои вычисления с реальными показателями.

Звучит так, будто вы ищете ответ типа «со скоростью, превышающей x запросов / мин, вы должны использовать опрос вместо SSE», и я не думаю, что есть ответ, который так прост. Это зависит от гораздо большего, чем количество запросов / мин или запросов / сек.

1 голос
/ 29 апреля 2019

«Голосование» влечет за собой накладные расходы на все стороны.Если вы можете избежать этого, не опрашивайте.

Если SSE - вариант, это может быть хорошим выбором.«Это зависит».

В: Какие (если они есть) какие-либо «события» нужно обрабатывать вашему приложению?

...