Чаты, Комет, MySQL, PHP, Apache и прочая веб2.0 фигня
ГМейл, вконтекте.диалоги, ГТалк и пр. чаты.
Как я понимаю, все они работают по технологии Comet.
Цель одна: мгновенное получение сообщений и пр. обмен информацией.
У меня есть один написанный чатик, где каждые пару секунд инициируется соединение АЯКСом и вынимаются данные из БД.
Понимаю, что это не совсем правильно, но. что есть.
Почитал статьи о Realplexor'e и вот такую статейку про реализацию поддержки длительных соединений...
С пониманием РеалПлексора у меня туго, хотя бы потому что некуда его поставить, не на чем протестить, нужен сервер. А вот по поводу статьи:
Вопрос №1: Реально ли снизится нагрузка, если мы говорим не о 30 соединениях, а о 10.000 ?
Ведь это 10.000 постоянно висящих в памяти и исполняющихся php файла с установленными слипами.
Возможно ли как-то у себя на локальном сервере сэмулировать подобную нагрузку? подскажите варианты решения.
-----
Допустим 10.000 исполняемых скриптов вполне нормально живут на тазике и нагружают его процентов на 20-30.
Вопрос №2: А как при этом живется MySQL, у которого мы каждый раз спрашиваем наличие новых сообщений (т.е. указываем идентификатор последнего полученного и вынимаем все те, у которых ID больше)???... При этом эти 10.000 скриптов, как я понимаю, создают 10.000 подключений к серверу MySQL...
И это за 1-5 секунд нужно сделать 10.000 запросов к файлам с БД... Веники не умрут?
Или здесь мои представления о работе MySQL не верны?
-----
И последний вопрос, по поводу работы MySQL.
Все таблицы и базы хранятся на жёстком диске в виде файлов. Что делает дисковую подсистему узким местом (как оно всегда и было).
Возможно ли каким-то образом создавать временные таблицы непосредственно в оперативной памяти сервера, без записи оных на НЖМД, например при старте MySQL или при первом обращении скрипта-PHP к этим таблицам, а-ля:
if(!mysql_select_db("tmp_base") ) {
exit;
}
else {
// Спрашиваем БД что нам нужно.
}
Ну и держать её (таблицу) в памяти постоянно, временами записывая её содержимое в нормальную БД для сохранности и удаляя из временной таблицы результаты, которые сохранены, и оставляя её размер в оперативной памяти на уровне ДО 10мб (в реальности - до 1МБ)...
Или все временные таблицы всё равно пишутся на ХАРД и такой возможности (создавать таблицы строго в опреативной памяти) не существует???...
=============
Спасибо тем, кто прочёл до конца...
Еще бОльшее спасибо тем, кто поддержит дискуссию и наставит на путь истинный.
Создание БД в оперативной памяти:
CREATE TABLE `our_db`.`test_tbl` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`textfield` VARCHAR( 255 ) NOT NULL ,
`more` BIGINT NOT NULL
) ENGINE = MEMORY;
Важно:
1. ENGINE = MEMORY - таблица (а точнее - её данные) умрет после перезапуска SQL сервера.
2. Данный тип таблицы не поддерживает типы полей BLOB и TEXT, потому удачным костылем будет использование VARCHAR с любой длиной поля.
ИМХО, назначение такой таблицы - быстрая работа с данными, которая не представляет из себя какой-либо практической ценности, когда нужно очень быстро делать выборку, поиск, запись новых полей. Примером таких данных я вижу чат и подобные сервисы. Дисковая подсистема - самое слабое место в БД (ИМХО), по-этому если у нас много клиентов - они работают с таблицей в оперативной памяти (пропускная способность которой изменяется гигабайтами в секунду), а данные из этой таблицы с интервалами (например в 1 минуту или в 10) сливаются в таблицу постоянного хранения...
Кто что думает на эту тему?
З.Ы. варианты, если БД у нас в пределах 50-100мб, но нужна быстрая работа - можно хранить данные в постоянной таблице, при старте сервера выгружать данные в таблицу в оперативке, периодически сохранять результаты работы с временной БД в постоянную. И максимальное время отката работы - только то, которое вы укажете в скрипте, который возвращает данные в таблицу на диске.
Не знаю, правильно ли я провел тесты:
SELECT BENCHMARK( 1000000, ENCODE( "hello", "goodbye" ) ) FROM message \\--- 1,1336 с
SELECT BENCHMARK( 1000000, ENCODE( "hello", "goodbye" ) ) FROM test \\--- 0.0006 с
Имеет ли право на жизнь такой принцип работы?
Что вы думаете по поводу хранения текстовых данных в такой таблице? (а не только индексов) (в виде VARCHAR 255-500 символов)?
