Будет ли сокет-соединение превзойти анализ и запросы базы данных Intarvaled?

Question

Я создаю небольшое приложение для чата, чтобы добавить его в существующий фреймворк. В каждый момент времени будет только 20-50 пользователей максимум .

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

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

У меня плохое начало?

Заранее спасибо -J

(p.s. Это полузакрытая сеть за логином php, так что безопасность не имеет большого значения)

Answer 1

Прежде всего, я бы предложил прочитать о JavaScript Long Polling , чтобы мгновенно получить ваши данные.

Что касается сбора и распространения ваших данных, я бы порекомендовал вам использовать базу данных, которая поддерживает LISTEN и NOTIFY.(Например, Postgres предоставляет вам pg_get_notify () в PHP)

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

Другие ресурсы и ссылки:

• http://www.postgresql.org/docs/current/static/sql-notify.html
• http://www.postgresql.org/docs/current/static/sql-listen.html
• http://www.php.net/manual/en/function.pg-get-notify.php
• http://blog.perplexedlabs.com/2009/05/04/php-jquery-ajax-javascript-long-polling/
• http://en.wikipedia.org/wiki/Comet_%28programming%29
• http://www.webdevelopmentbits.com/avoiding-long-polling

Answer 2

Во-вторых, длинный опрос - это хороший подход. Тем не менее, понять это и сделать это правильно, гораздо сложнее, чем просто опросить с интервалами. С 20-50 пользователями масштабируемость не должна быть проблемой. Для хорошего дизайна длинных опросов вы должны посмотреть, как избежать приостановки серверного потока на время существования запроса http.

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