серверный пуш или клиентский пуш лучше?

Question

Я занимаюсь разработкой веб-сайта чата с использованием jsp / servlet. Я буду размещать свой веб-сайт на gooogle appengine. Теперь у меня есть некоторые сомнения относительно использования технологии push server или client pull

1) Если я использую push сервера и если я не закрываю ответ сервлета, это заставит сервер работать медленно? Сколько одновременных соединений может обработать сервер tyicall tomcat, если я оставлю сокет открытым для всего сеанса чата между 2 клинтами ??

2) Будет ли сервер лучше или клинет лучше?

Answer 1

Если вы используете сервлет (до версии 3.0), то, я думаю, вам придется использовать pull из-за модели программирования сервлета. Тем не менее, есть преимущества в использовании модели push . В первую очередь, бесполезная трата нагрузки на сервер и ограничение задержки. Вот почему существуют такие технологии, как комета . Servlet 3.0 также поддерживает push-модель . Они обычно используются в приложениях на основе ajax.

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

Если вы используете реализацию на основе nio для push-модели, вы можете поддерживать тысячи или даже более 10 000 одновременных подключений (очевидно, ваш размер варьируется).

Если вы используете традиционную реализацию на основе ввода-вывода, она, вероятно, будет в диапазоне сотен одновременных соединений (хотя не принимайте эту оценку слишком серьезно. Я просто даю эти цифры, чтобы дать очень, очень грубое ощущение ).

Что касается tomcat, в последний раз, когда я проверял, люди говорили, что у него не будет хорошей поддержки push-модели до версии 7.0. Но я не слежу за текущим статусом, поэтому я не уверен (извините, возможно, кто-то еще может помочь вам в этом). Если это так, вы можете проверить поддержку кометы jetty.

grizzly и netty также являются хорошими сетевыми платформами на основе NIO, но если вы захотите использовать JSP и обнаружите, что tomcat недостаточно, я думаю, лучшим решением будет Jetty.

edit: (дополнительная информация) В этих «push-моделях» сервер не открывает соединение с клиентом. Соединение будет поддерживаться, и сервер будет отправлять сообщения так, как считает нужным.

Кроме того, это не похоже на то, что есть только модели "push" и "pull". Вы можете иметь гибрид, как длинный опрос.

Answer 2

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

Answer 3

Ответ на ваш запрос зависит от того, какой протокол вы хотите использовать. Поскольку вы упомянули JSP / сервлеты, ваше приложение будет реализовано по протоколу HTTP.

HTTP - это протокол по TCP. TCP ориентирован на соединение и остается активным до тех пор, пока соединение не будет завершено. Однако HTTP-соединения являются постоянными, только в течение одного цикла запрос-ответ. TCP-соединение разрывается после каждого цикла запрос-ответ. Так что это должно ответить на ваши сомнения относительно того, сколько сокетных соединений сможет обработать типичный сервер TOMCAT. Соединения не будут постоянными, вообще. Они будут действовать только в течение цикла HTTP-запроса-ответа.

Исходя из этой базовой идеи, я бы предложил вам использовать стратегию вытягивания клиента для реализации вашего приложения. Даже при использовании push-сообщений через HTTP, хотя имя и говорит «server push», это всегда веб-клиент, который опрашивает сервер через равные промежутки времени, что создает иллюзию «server-push». Спецификация HTTP требует, чтобы клиент делал запрос, на который отвечает сервер.

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

Answer 4

Если я использую push-сообщение сервера и не закрываю ответ сервлета, это приведет к медленной работе сервера?

App Engine не позволит вам сделать это. Вы должны закончить свой ответ в течение тридцати секунд, иначе он будет убит. Тридцать секунд - также крайний случай, большинство вычислений, которые они делают (для квоты и тому подобное), основаны на времени отклика 75 миллисекунд.

Сколько одновременных соединений может иметь сервер Tyicall Tomcat

Tomcat? Я думал, что вы планируете использовать App Engine?

Answer 5

Прицепные. Всегда тяни.

Я знаю, что это книга, ориентированная на производство, но совет Lean Thinking (Womack & Jones) неоценим в любом контексте (грубо говоря, по памяти):

Начните с определения значения , выстроить действия, которые создают ценность в потоке создания ценности , создать поток через поток создания ценности, пусть клиенты извлекают значение из потока создания ценности, конкурировать с совершенством , а не с другими организациями

Если я их неправильно процитировал, прошу прощения. В любом случае, все эти принципы могут быть легко применены при разработке любого программного продукта так же, как и при производстве любого физического продукта, но для вас важен pull .

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

Я не совсем понял ваш первый вопрос, но ответ все еще pull .