Я брошу сюда свою шляпу, даже если это старый вопрос.По скорости, надежности и простоте использования БД является очевидным легким выбором ... С одним серьезным предостережением, которое пропускают многие люди, а именно с большинством общих хостов (наиболее распространенная форма веб-хостинга) разрешено только 15 илиТаким образом, соединения сразу, даже VPS обычно разрешают только 100-200, а выделенные - 500 или более.Это означает, что если у вас есть (n) пользователей, объединяющих пулы каждые (s) секунд, эти соединения будут быстро израсходованы, даже быстрее, если вы также используете какой-либо CMS.Находясь в процессе разработки собственного кода чата на VPS, я тоже сам сталкиваюсь с этими проблемами.
Пока мой метод был таким:
- Обязательно пройдитеПеременная lastMessageReceived для ограничения ответа.
- Если общедоступный чат передает фильтр отметок времени, а также приведенный выше
- , если это вообще возможно, использовать механизм кэширования БД, такой как MySQLnd, с включенным кэшированием запросов и TTL.установите любую скорость пулирования.
- Не сходите с ума от скорости пулирования. 1-2-секундные интервалы могут показаться аккуратными и быстрыми, но это убьет количество ваших соединений.Снижение этого до 5 с или даже больше не будет иметь большого значения, и пользователи, вероятно, не заметят, и нагрузка на ваш сервер будет намного меньше.Даже учитывайте переменную частоту пула, которая повышается во время высокой нагрузки.
- Напишите ваш ajax, чтобы использовать тайм-аут вместо интервала для его пула, и поместите вызов timeout в обратный вызов ajax success, это предотвратит суммирование запросов во времяpeak ussage.
- И самый большой, если вы используете общий чат с большим количеством пользователей, напишите свой собственный код для кеширования SQL-запроса в файл json, затем отправьте его в ajax-запросы и напишите некоторый пользовательский код TTL.Чтобы проверить его возраст и повторно заполнить его по мере необходимости во время запросов, CRON был бы здесь полезен, если ваш хост позволяет.Проверка возраста файла и перенаправление на него AJAX-запроса - это функция более высокого уровня с минимальными нагрузками на сервер, особенно по сравнению с запросами к БД.И не анализируйте файл в PHP, пытаясь отфильтровать старые сообщения, сохраните файл с первым сообщением в имени файла, например
chat_243.json, и сохраните его как уже отформатированный json, а затем просто подайте весь файл, если поступит запросв php с lastMessageReceived = 243.Так как это создаст несколько файлов, вам понадобится функция для очистки файлов старше (м) минут, но это также легкая работа для сервера.
Существуют также такие варианты, как разработанные механизмы БДдля чата и сокетов (node.js), но для них требуется больше настроек сервера, чем позволяют обычные учетные записи хостинга, для моих целей я писал свой чат, имея в виду, что в какой-то момент он может быть развернут на общем сервере.
Вот код, который я использую в настоящее время, и он в значительной степени позволил мне расширить свой чат до неограниченного количества соединений (в пределах пропускной способности серверов)
$cacheFile = 'cache/chat_'.$_GET['last'].'.json';
if (file_exists($cacheFile) && filemtime($cacheFile) + QUERY_REFRESH_RATE > time())
{
readfile($cacheFile);
} else {
require_once("../../../../wp-load.php");
$timestampMin = gmdate("Y-m-d H:i:s", (time() - 7200));
$sql= "/*qc=on*/" . "SELECT * FROM ". DB_TABLE ."chat_posts WHERE ID > ". $_GET['last'] . " AND timestamp > '".$timestampMin."' ORDER BY ID;";
$posts = $wpdb->get_results($sql);
$json = json_encode($posts);
echo $json;
file_put_contents($cacheFile,$json);
}