Как сделать чат в javascript / php более эффективным с точки зрения времени загрузки и взаимодействия с SQL

Question

Прямо сейчас настройка для моего чата javascript работает так, что она выглядит как

function getNewMessage()
{
     //code would go here to get new messages
     getNewMessages();
}
getNewMessages();

И в рамках функции я бы использовал JQuery, чтобы сделать пост get для получения сообщений из php-скрипта, который будет 1. ЗапуститьСоединение с SQL 2. Проверьте, что он является законным пользователем через SQL 3. Получите только новое сообщение с момента последнего посещения пользователя 4. Закройте SQL

Это прекрасно работает, а чат работает отлично.Меня беспокоит то, что это открывает и закрывает много соединений SQL.Это довольно быстро, но я бы хотел сделать небольшую многопользовательскую игру на javascript и передавать пользовательские координаты, а также десятки других переменных 3 раза в секунду, в которых я каждый раз открываю и закрываю соединение sql и извлекаю информациюиз множества таблиц каждый раз может оказаться недостаточно эффективным для бесперебойной работы, а также может быть слишком напряженным для сервера.

Есть ли лучший, более эффективный способ передачи всех этих переменных, о которых мне следует знать, какие изне так тяжело на моем сервере / базе данных?

Answer 1

Не используйте постоянные соединения, если только это не единственное доступное вам решение!

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

Если вы не измерили, сколько времени требуется для соединения и не определили его как очень большой процент времени выполнения вашего скрипта, вам не следует использовать постоянные соединения. На самом деле, это должно быть то, что вы делаете здесь, если вы беспокоитесь о производительности. Проверьте xhprof или xdebug , профилируйте свой код и начните оптимизацию.

Answer 2

Я знаю, что это довольно раздражающий «ответ», но, возможно, вам следует подумать об этом по-другому, ведь это действительно не самое сильное использование реляционной базы данных.Рассматривали ли вы решение XMPP?IMO, это был бы лучший инструмент для работы, и ejabberd и openfire тривиально настроить в эти дни.Превосходная библиотека Strophe может упростить внешний интерфейс, а в качестве дополнительного бонуса вы получаете HTTP-привязку (например, commet), поэтому вам не нужно будет опрашивать сервер, ваша задержка снизится и вы будете генерировать меньше HTTP-трафика.

Я знаю, что очень маловероятно, что вы измените весь свой подход, просто потому что я так сказал, но хотел предоставить альтернативную перспективу.http://code.stanziq.com/strophe/

Answer 3

Пара дюжин игроков одновременно не повредит базе данных и не вызовет заметного лага, если у вас есть эффективные операторы SQL.Скорее всего, ваша база данных будет размещена на том же сервере или, по крайней мере, в той же сети, что и ваша игра или сайт, так что не беспокойтесь.Если ваша БД размещена на отдельном сервере с 8-битной платой 16 Мц, загруженной MSDOS, расположенной в удаленном Амазоне, подключенной радиоволнами, подключенными к генератору с питанием от коленчатого вала, управляемым пьяной обезьяной, вы подключенысвой собственный с этим.

В противном случае, действительно, вам следует больше беспокоиться о том, сколько именно данных вы передаете игрокам взад и вперед.Если вы передаете туда и обратно координаты для всех объектов во всем мире, загрузка страницы может занять мучительно много времени, даже если запрос БД занимает доли секунды.Это иногда преодолевается в играх функцией «тумана войны», которая не мешает уведомлять пользователя о каждом объекте на всей карте, только о тех, которые находятся в непосредственной близости от игрока.Это легко сделать с помощью одного SQL-запроса, где координаты объекта находятся рядом с игроком.Хотя, если у вас скупой хост, они позаботятся о количестве подключений и запросов.

Если вы хотите привлечь еще больше игроков, рассмотрите возможность использования методов кэширования, таких как предварительное построение хранения коротких файлов.часто выбираемые записи или значения с использованием fopen(), fgets(), fclose() и т. д. Или используйте расширения php, например apc, для хранения значений в памяти, которые сохраняются от загрузки страницы до загрузки страницы.memcache или memcached также действуют аналогично, но действуют как отдельный сервер, к которому вы можете подключиться, сохраняете значения, которые можно использовать совместно с другими обращениями к страницам, и запрашиваете.

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

Опять же, если вы не находитесь под жестким пальцем скупого хоста или если вы не 'Вы получаете сотни и более просмотров страниц за раз, не нужно даже беспокоиться о вашей базе данных.Базы данных не такие хрупкие.Если они падали в истерическом приступе слез в любое время, когда на их пути появлялось больше одного запроса, инженеры, которые его выполняли, не могли долго работать.

Answer 4

http://www.php.net/manual/en/features.persistent-connections.php

и

http://www.php.net/manual/en/function.mysql-pconnect.php

Answer 5

Возможно, попробуйте использовать другой подход для получения новых сообщений от сервера: Comet .

Используя эту технику, вам не нужно открывать столько новых подключений.