[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Кеширование!
Страницы: 1, 2, 3
I++
Если твой чат подразумевает работу в режиме:
1. Грузим статику.
2. Обновляем окно с сообщениями по принципу стека.

То от файлового кеша толку мало, количество попаданий в кеш будет минимально, т.е данные из кеша будут браться только в том случае если пользователь грузит страницу с чатом с нуля. Такие ситуации редкие, либо возникают во время злонамеренных запросов, чтобы сломать чат smile.gif

Если твой чат обновляется по принципу:

1. Грузим страницу с нуля.
2. Обновляем страницу, новые сообщения обновляются (принцип форума)

То в данном случае файловый кеш имеет место быть, но не при 9000 каналов, где идет обширный флуд каждую секунду.

Есть еще гибридный режим.

1. Грузим страницу с нуля.
2. Обновляем страницу, новые сообщения обновляются (принцип форума)
3. Если пользователь не обновляет страницу, делаем это сами через ajax, но в данном случае обновляем только сам чат. В файле кешируем готовый json с сообщениями.

Вопрос в другом зачем вообще использовать базу данных? Только если нужно логи вести или еще что-то делать в дальнейшем.

Самый быстрый метод с большим количеством коннектов это первый, только на сокетах а не ajax, тут уже событийная модель может работать, а значит меньше трафика и использование проца, хотя чат проц почти не использует, но если 90к коннектов через прослойку апача будут стучать в итерации php скриптов, то проц нагрузят и памяти отожрут нормуль, а так можно держать 1 инстанс и удобно управлять потоками инфы в пределах 1 процесса.

Так, что нужно определиться какой тип чата будет, делать 9000 комнат с кешем на файлах микроскопических не выгодно, а вот если комнат немного например 10 то вполне прокатит. субд для чата не вижу особого смысла делать, ну если только хранить информацию о юзерах, а вот месаджи там держать и дергать их от туда как по мне не рационально, если только не нужно эти сообщения еще гдето обрабатывать или использовать, например транслировать чат на 5 сайтах на разных серваках, но опять таки можно кешем обойтись smile.gif
Zzepish
I++
В файлах сообщения- не удобно! Да у меня ж не только чат- у меня целый сайт будет.

Обновлять как? При добавлении\удалении сообщения запрос к базе на обновлени кеша?

Я понимаю так: сообщения хранить в кеше намного выгодней ,если у меня может быть много каналов!

Раз через сокеты- мне понадобится: http://php.net/manual/ru/book.sockets.php и технология с сокетами на аяксе? Или се намного проще: пилю на клиенте web-sockets, при изменении данных в кеше меняется и содержимое страницы?
Zzepish
Скажите, я хоть в правильном направлении думаю?
I++
Я понимаю так: сообщения хранить в кеше намного выгодней ,если у меня может быть много каналов!

Точно, только если этот кеш будет в озу торчать, а не кучу мелких файлов разбросанных по всей поверхности диска. Файловый кеш оправдан до той поры пока таких мелких файлов не много, а когда их много вот тогда, толку 0. Я об этом уже писал. Если на серваке память не под завязку забивается и обновления не скачками, то вызов fopen повторно будет закеширован, чтобы харду не пришлось повторно искать и читать, там будет примерно так:

1 вызов займет 20 ms допустим
2. вызов уже займет меньше 1 ms, потому что данные будут браться из кеша на уровне ОС.

Так, что если будешь делать 9000 каналов, забей на файловый кеш, если с 10ток каналов, пользуйся smile.gif

Сокеты с демоном не каждый хостер дает. Во 2 если решил пойти по пути сокетов встроеных, нужен будет socket non block и socket select. Нормального описания ПРАВИЛЬНОЙ работы возможно можно найти на хабре.

Сразу скажу при записи сокет может вообще 0 байт отправить, а на чтении по 1 символу слать тот же json, так что в примерах где это не учитывается лучше отбросить, таких примеров в инете 90% злопримеров.

Так, что я libevent люблю smile.gif Там не нужно с этим пвриться. Просто: горшочек вари! Как в том мультике и время уже тратится на более важные вещи.

А так, я бы не стал замудряться если хостер злой гад, и сделал бы как тут чат smile.gif
За час такой чатик можно сделать на файле обычном.
Zzepish
I++
у меня повышение квалификации) так что я просто осваиваю технологию) огромное спасибо за советы)
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.