Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > PHP: Общие вопросы > Механизм чата


Автор: Bog d`An 25.1.2009, 04:56
Может и полный нуб, но вопрос. Каждые две секунды, допустим надо отдавать пользователю данные о текущем состоянии дел в чате. 
Если это идёт запрос в мускул за минутут получаем 30 запросов (и это только часть из возможных)
получаем 30*60=1800 запросов в час. На хосте стоит ограничение 10000запросов в час. 
получается одновременно около5ти человек могут общатся. Нехорошо...

Вопрос. как сделать что-то по типу (или просто без что-то типа) кеширования. Ведь не обязательно каждые две секунды обновляется инфа...
Спасибо и извините)

Автор: xbelyi 25.1.2009, 10:30
Я бы в таком случае посоветовал демон писать, но раз ограничение на хостинге даже на количество запросов к БД, то это не удасться. Ведь невозможно указать браузеру, когда надо обновлять информацию, а когда не надо, без сокетов.

Единственным, как мне кажется, решением является ставить запрос в 5-7 секунд, ибо очень тяжело будет читать страницу, обновляющуюся каждые 2 сек.

5сек на запрос, 12 запросов в минуту, 720 в час, 14 человек, что впрочем тоже плохо.

Автор: ksnk 25.1.2009, 11:11
Ну, раз такая пьянка - пишите новые сообщения в файл. Раз в минуту один из скриптов будет сливать в базу все сообщения одним запросом. Все скрипты выводят сообщения из базы + сообщения из файла.

можно хранить новые сообщения в Memcache

Автор: Bog d`An 25.1.2009, 13:47
ksnk, так, в принципе и думал... вопрос - это сильно нагружает систему? 

ссылочки по теме не порекомендуете?

Автор: ksnk 25.1.2009, 14:31
про http://ru2.php.net/manual/ru/book.memcache.php? Это отдельное расширение, впрочем, довольно распространенное.

Добавлено @ 14:33
А так - идея проста - сериализованный масив из новых сообщений хранится в файле. Работа с файлом должна проходить через flock... Вот , собственно и все... smile

Автор: Bog d`An 25.1.2009, 18:55
я так понимаю это какой-то демон? 
я могу его прикрутить к скрипту, если доступ только для моей папки и прочие злобные ограничения стоятЪ))

или придётся ещё доплачивать за его работу? =-.-= там вроде для демонов отдельные тарифы

Автор: enof 25.1.2009, 20:01
С такими ограничениями наверное стоит забыть о БД.
Например каждые 5 секунд(желательно конечно меньше,а не то форум получится) аякс дергает скрипт.
Каждый раз доставать все сообщения накладно,поэтому сначала нужно узнать,появились ли новые сообщения и только
потом тянуть нужное.
от одного человека получается:
1 запрос в 5 секунд + 0.5( предположим,что сообщения в штатном режиме будут появляться 1 штука в 10 секунд).
1.5 * 60 * 60 = 5400 запросов в час от одного человека,который ничего не будет писать.
Плюс по запросу на каждое отправленное сообщение.
Даже мегаэстонский чат не получится,если только сидеть будут по 20 минут в час.

Как вариант можно каждому юзеру при входе заводить свой файл и писать в него цифру.
0 = нет сообщений.
N = n новых сообщений в базе.
Аякс делает запрос к скрипту,скрипт проверяет файл юзера,если есть новые сообщения достает их из базы и 
записывает ноль в файл.
При отправлении юзером сообщения,скрипт пишет его в базу,и обновляет все файлы,инкрементирую записанное значение 
в файле.
Только при этом варианте придется позаботиться о сохранности очереди при записи\чтении файлов.
Бред какой-то получается,лучше полностью тогда на файлах все делать smile

Добавлено через 1 минуту и 11 секунд
А еще лучше нормальный хостинг купить smile 

Автор: NNaarreekk 25.1.2009, 22:13
Я не понял ачто хостингу пофиг какой запрос?
То есть всю инфу берешь или отдельный строку??

Автор: enof 26.1.2009, 14:10
NNaarreekk, Смотря что хостер считает запросом.
mysql_select_db тоже ведь запрос делает.
mysql_insert_id тоже,не из воздуха же функция значение берет.
mysql_fetch_* и т.д.

Цитата(NNaarreekk @  25.1.2009,  22:13 Найти цитируемый пост)
То есть всю инфу берешь или отдельный строку?? 

запрос-то один будет.А учитывается ли потом работа с результатом,хз.

Прояснить ситуация нам может только топикстартер.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)