Доброго вам время суток, Проблема такова, вообщем хочу написать чат на пхп. Слышал, что чат сделаный на пхп кушает 3-5Мб оперативки на человека,+ моментальное обновление не слишком красиво там делается... чат будет каждую секунду обращаться с запросом к серверу.... Вообщем нужен Ваш совет, как это все красиво и аккуратно реализовать, и самое главное что бы нагрузка на БД была как можно меньше, заранее спасибо.
Не обязательно, если грамотно продумать то вовсе не обязательно Не знаю точных цифр, но можно стараться снизить её до минимума
Сделай на файлах Вообще, пользователей и всякие конфигурации можно хранить в БД, но вот список сообщений ИМХО целесообразно хранить в файле.
Ты бы ещё предложил "убить себя ап стену", на форумах обычно помогать должны а не ржать над нубами... Это типа шутка такая ?
Dmitr IRC и веб-клиент на Джаве. Например, www.pjirc.com. Ну не сделаете вы удобнее/быстрее/экономнее/красивее при помощи ПХП/другого серверного языка.
Я всё-таки склоняюсь к мнению, что 10 раз за секунду прочитать файл быстрее, чем 10 раз в секунду подключаться к БД и делать запрос (конечно тогда надо чтобы в чате было хотя-бы 70 человек (тогда вероятность такой секунды вполне высока), и обновление списка сообщений у них было каждые 10 секунд) Если я чего-то не догоняю, объясни пожалуйста
ммм.. 1) про постоянные соединения ты не слышал? да и мускул соединяется с базой почти мгновенно 2) а если у тебя человек 300 активно чатится, то с записью в файл возникнет проблема. ну и приваты само собой тебе придется своим движком разбирать.. да и память у тебя может закончиться, файл то огромный выйдет 3) а сообщения вообще можно хранить не в базе, а в memcache. Ничего более быстрого, чем обращение напрямую к оперативной памяти, не придумано.
Ты не догоняешь одного, данные надо не только читать но и выбирать из них нужную информацию, и БД справится с этим в 10 раз быстрее, и потратит в 10 раз меньше оперативки чем РНР Много есть разных вариантов тот-же APC например, но если они недоступны то просто MySQL будет вполне достаточно (всё равно активно используемые данные кешируются, так что проблем с быстродействием быть не должно)
Хм а разве кэширование сообщений не будет мешать обновлению? Кроме того, при записи файл можно лочить, а чтобы не разрастался - хранить в нем последние Н сообщений... Хотя конечно вариант не идеальный, имхо браузерный чат на РНР идеальным быть не может
Предлогают не кэшировать сообщения, а отправлять их в память. Потом каждые n секунд/минут их собирать и слать в БД. Memcached пишет всё в оперативную память сервера. Э, а при чём тут PHP то? Ты не знаешь куда сообщения собирать, а виноват PHP.
я бы записывал сперва в базу затем - в memcache. Все таки база - основное хранилище. Хотя, в большинстве чатов информация не столь ценна, и потери сообщений за несколько секунд / минут - не существенны...
по поводу файлов... а как сделать защиту от двойнной записи в файл?? Что бы в один момент времени нельзя было дважды записать... и что будет с запросом если в тот же момент уже идет запись в этот файл... с защитой...