Как сделать чат-комнату javascript/php более эффективной с точки зрения времени загрузки и взаимодействия с SQL
Прямо сейчас настройка для моего чата 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 и извлекаю информацию из многочисленных таблиц каждый раз может оказаться недостаточно эффективным для бесперебойной работы, а также может быть слишком большой нагрузкой на сервер.
Есть ли лучший, более эффективный способ передачи всех этих переменных, о которых я должен знать, которые не так сложны для моего сервера / базы данных?
5 ответов
Не используйте постоянные соединения, если только это не единственное доступное вам решение!
Когда MySQL обнаруживает, что соединение было разорвано, все временные таблицы отбрасываются, любая активная транзакция откатывается, а все заблокированные таблицы разблокируются. Постоянные соединения сбрасываются только при выходе дочернего элемента Apache, но не при завершении вашего сценария, даже если сценарий завершается сбоем! Вы можете унаследовать соединение в середине транзакции. Хуже того, другие запросы могут блокироваться, ожидая разблокировки этих таблиц, что может занять довольно много времени.
Если вы не измерили, сколько времени требуется для подключения, и не определили его как очень большой процент времени выполнения вашего скрипта, вы не должны рассматривать использование постоянных соединений. На самом деле, это должно быть то, что вы делаете здесь, если вы беспокоитесь о производительности. Проверьте xhprof или xdebug, профилируйте свой код и начните оптимизацию.
Пара дюжин игроков одновременно не повредит базе данных и не вызовет заметного лага, если у вас есть эффективные операторы SQL. Скорее всего, ваша база данных будет размещена на том же сервере или, по крайней мере, в той же сети, что и ваша игра или сайт, так что не беспокойтесь. Если ваша БД размещена на отдельном сервере с 8-битной платой 16 Мц, загруженной MSDOS, расположенной в удаленном Amazon, подключенном радиоволнами, подключенными к генератору с питанием от кривошипа, управляемому пьяной обезьяной, значит, вы работаете свой с этим.
В противном случае, на самом деле вам стоит больше беспокоиться о том, сколько именно данных вы передаете игрокам взад и вперед. Если вы передаете туда и обратно координаты для всех объектов во всем мире, загрузка страницы может занять мучительно много времени, даже если запрос БД занимает доли секунды. Это иногда преодолевается в играх функцией "тумана войны", которая не мешает уведомлять пользователя о каждом объекте на всей карте, только о тех, которые находятся в непосредственной близости от игрока. Это легко сделать с помощью одного SQL-запроса, где координаты объекта находятся рядом с игроком. Хотя, если у вас скупой хост, они позаботятся о количестве подключений и запросов.
Если вы хотите привлечь еще больше игроков, подумайте о том, чтобы изучить методы кэширования, такие как предварительная сборка коротких файлов, в которых хранятся часто извлекаемые записи или значения, используя fopen(), fgets(), fclose()и т. д. Или используйте расширения PHP, такие как apc хранить значения в памяти, которые сохраняются от загрузки страницы до загрузки страницы. memcache или же memcached также действуют аналогично, но таким образом, что действуют как отдельный сервер, к которому вы можете подключиться, сохраняете значения, которые можно использовать совместно с другими посещениями страниц, и запрашиваете.
Чтобы обновить кэшированные страницы или значения, когда вы думаете, что они могут устареть, вы можете запускать задание cron очень часто для обновления этих файлов или значений. Если ваш хост не разрешает задания cron, рассмотрите возможность сделать так, чтобы ваши гости выполняли эту работу: строка сценария на определенной странице обновит кэш новыми значениями из запроса к базе данных после определенного числа обращений к странице. Или кэшируйте значение даты для проверки при каждом обращении к странице, и, если прошло так много времени, обновите кэш.
Опять же, если вы не находитесь под жестоким пальцем скупого хоста или если вы не получаете сотню или более просмотров страниц за раз, нет необходимости даже беспокоиться о вашей базе данных. Базы данных не такие хрупкие. Если они падали в истерическом слезе каждый раз, когда на их пути появлялось больше одного запроса, инженеры, которые его выполняли, не могли долго работать.
Возможно, попробуйте использовать другой подход для получения новых сообщений от сервера: Comet.
Используя эту технику, вам не нужно открывать столько новых подключений.
Я знаю, что это довольно раздражающий "ответ", но, возможно, вам следует подумать об этом по-другому, ведь это действительно не самое сильное использование реляционной базы данных. Рассматривали ли вы решение XMPP? IMO, это был бы лучший инструмент для работы, и ejabberd и openfire тривиально настроить в эти дни. Превосходная библиотека Strophe может упростить создание внешнего интерфейса, а в качестве дополнительного бонуса вы получаете HTTP-привязку (например, commet), поэтому вам не нужно опрашивать сервер, ваша задержка уменьшится, и вы будете генерировать меньше HTTP-трафика,
Я знаю, что маловероятно, что вы полностью измените свой подход, потому что я так сказал, но хотел предоставить альтернативную перспективу.