Я создаю backend-модуль (написанный на PHP), который будет использоваться для мониторинга частных чатов, не имеющих активности для [Точно] 300 секунд (5 минут) . Если это так, скрипт обновит базу данных (устанавливает максимальное количество пользователей на определенный номер и другие материалы). Я контролирую промежуток времени простоя на разницу во времени now () и отправленного последнего сообщения.
Что я сделал: установите задание cron, которое будет запускать (через php-cli) мой скрипт мониторинга каждую минуту или 60 секунд. Внутри сценария мониторинга:
$expire_time = time() + 60; //this loop will run for 60 seconds while(time() < $expire_time) { $idle_time = get_all_chatrooms_idle_time(); foreach($idle_time as $s_time) { if($s_time >= 300) { update_changes(); } } usleep(500000); } Условие мгновенной настройки максимальных пользователей после 300 секунд бездействия не может быть достигнуто. Поэтому я не могу следовать советам, например: «избегайте делать что-либо, пока что-то на самом деле не потребует его», хотя это имеет большой смысл.
Причина? Данные активных и неактивных чатов должны быть в реальном времени, потому что они также будут отображаться на приборной панели. От этого зависит плата модераторов в чате.
Почему бы не проверить их на каждую нагрузку на приборную панель? Извините, но все еще невозможно.
Проверка должна быть серверной, а панель мониторинга обновляется с помощью ajax, опроса каждую секунду.
Когда я прикрепляю код мониторинга к странице, запрашиваемой моими вызовами ajax, я думаю, что это более ресурсоемкий, чем моя текущая реализация (исправьте меня, если я ошибаюсь)
Позвольте мне дать вам приблизительную оценку количества пользователей, чтобы вы могли представить, какую нагрузку / трафик мы получаем:
(x) – можно просмотреть панель приборов
Есть ли способ лучше? Правильно ли я это делаю?
Этот цикл является излишним. Он может работать много тысяч раз в минуту, даже на умеренном сервере, и он генерирует высокую загрузку процессора даже для приложения реального времени. Добавьте счетчик и просмотрите счетчик итераций. Я думаю, что это создает еще большую нагрузку, чем обработка по каждому запросу AJAX.
Прежде всего, определите степень детализации, с которой вам нужна информация. Предположим, вы решили иметь 3 секунды детализации (например, прокручивая базу данных каждые 3 секунды) – это число может быть слишком высоким для вас, но это показывает, что вы не теряете много. Когда AJAX тянет каждую секунду, вы МОЖЕТЕ видеть некоторые счетчики, которые должны ползти непрерывно сканировать назад один или два раза. (Будете ли вы действительно видеть, что такое зависит от природы ваших счетчиков.)
Если ваши счетчики основаны на данных в диапазоне секунд (например, показывая суммы прошедших секунд или суммы, основанные на $ / сек), то во-вторых, потяжка AJAX не будет обеспечивать непрерывные счетчики. (Иногда он пропускает второй или обновляется до второй раз, по сетевым причинам).
Независимо от выбранной гранулярности ваша окончательная статистика будет в порядке, потому что они основаны на абсолютных временных отметках – независимо от того, как поздно они оцениваются.
Если во второй раз опрос AJAX используется для реализации гладкого счетчика, чем вы можете сделать намного лучше, чем это: подсчет должен выполняться на стороне клиента (например, отправка значений с их вторым шагом: revenue: <span data-inc="25">14432</span> и подсчет с помощью JS). Единственный инструмент AJAX для контроля состояния счетчиков остановки / реселлера. Затем вам нужно только определить, как долго оповещение может опоздать (например, 10 секунд), после чего счетчики будут перескакивать для макс. 10s – возврат к ожидаемому значению. В этом случае вы не должны чаще выполнять очистку БД (например, половину интервала). Это позволяет, например, для 3-секундного сна в вашем цикле, что резко снижает нагрузку.
Если вы можете легко добавить добавление метки времени истечения каждого чата в базу данных (либо в записи, либо фиксированную) с индексом, который ускорит чтение бит (и дополнительно разрешит правила истечения срока действия для каждого номера).
Я за комментарий рекомендую использовать такую технологию, как node.js , которая представляет собой асинхронную платформу ввода-вывода с четным управлением для создания приложений. Если чат – это внешнее приложение, вы можете легко открыть сокет и послушать чат, зарегистрировать его, проверить активность пользователей и прослушать определенные события.
#!/usr/bin/php <?php if( file_exists('/tmp/chatrooms_cron.lock') ) { die( 'There is already a script running.' ); } file_put_contents( '/tmp/chatrooms_cron.lock', 1 ); // Storing pid would be better // Run loop forever while( true ) { $idle_time = get_all_chatrooms_idle_time(); foreach($idle_time as $s_time) { if($s_time >= 300) { update_changes(); } } sleep( 60 ); }
Совет для node.js (с socket.io):
Я использую node.js для работы на своем отлично! Будет работать в реальном времени и работать с браузерами до ie5 / ie6. Это можно сделать внутренне в node.js.
setInterval( function() { // Fetch and update peers }, 300000 );