Нет, речь о том, что один клиент монополизирует работу ядра чата. Попробую погуглить на эту тему, в общем. Угу, а значит нужно делать внутренний буфер и выдавать клиенту ровно столько, сколько может принять буфер ОС. В общем, по большому счету, всех задержек можно избежать... если иметь хороший опыт в таких делах. Но, имхо, в таких случаях делать ядро на ПХП... ну неразумно... ибо большинство операций низкого уровня. Вот скриптовый обвес - это да, а из ядра выкинуть все лишнее, переписать на С - и будет у тебя не 500, а 50000 тысяч клиентов =) Не.. при форкании у тебя стопорит операции IO только того клиента, процесс которого застопорило. Хотя тут тоже без головы не обойтись. Э... это не "вообще", это так и есть. По сути классическая схема - пришел клиент, на него форкнулся процесс и висит, работает с ним. В случае ПХП да... это смерти подобно =)
MiksIr, разумеется у меня есть стэк с буферами на чтение и на запись сокетов, иначе они бы вешали ядро чата. Если бы этого небыло, можно было бы злонамеренно коннектиться к серверу и висеть ничего не делая, подвешивая собой всё ядро демона. Подвешивание любой IO операции на любом сокете никак не сказывается на работе сервера, такой сокет просто игнорируется до изменения его статуса, а если статус не изменится за отведённый таймаут, соединение будет оборвано со стороны сервера. "Классическая схема" мне совершенно не нравится -), это корявое и "дорогое" решение. Про 50000 это не реально, даже 5000 есть сомнения. Я тестил с помощью ab обработку "неправильных" HTTP запросов моим чат сервером и апачем 2.0.53, апач отрабатывал их всего в ~3 раза быстрее, ничего выдающегося, незнаю что он там делает, но меня не впечатлило.
читаю и балдею ... дочего ж слова знакомые ... форкнуть, сокет, буфер, клиент ... прям бальзам на душу ... спасибо. умилили отца ...
Как работает select я знаю. Речь идет о блокирующем выводе... у ОС есть буфер, куда ты можешь пихать данные, а они отдаются клиенту. Но если данные идут быстрее, чем клиент их забирает из буфера... то будет косяк, т.е. или у тебя будет блокирующий вывод, что неподходит, или у тебя будет ошибка записи в сокет и потеряются данные. Что бы этого не происходило, тебе нужно свой буфер выводимых данных. А насчет корявого и дорого решения.. не забывайте, что апач так работал (да и работает - мало кто тредовый 2.0 использует)
MiksIr, 1. я же написал, у меня как раз 2.0.53 апач. 2. В последней версии чат сервера у меня есть стэк с буферами на запись, вообще все операции сокетами у меня не блокирующие. Если соединение с клиентом подвисло, то в сокет будет записан лиш кусок размером с буфера ОС, а оставшийся кусок будет дожидаться изменения статуса сокета, при этом не будет никакого простоя, всё очень эффективно. Осталось только протестировать на реальной нагрузке. -) 440Hz, так что там с ботом то?
Все еще бьюсь над обновлением. Не получается... Можете подробно расписать технологию со скрытым фреймом, пожалуйста?
Так же есть к примеру файл http://localhost/somedir/somefile.php?Admin Как можно вытащить то что стоит после "?" Т.е значение из УРЛ передать переменной: PHP: $username = "Admin";
Мавир, это я знаю ))) Только не нашел там ответа на свой вопрос... =( И подскажите пожалуйста про скрытый фрейм )
PHP: $load_time = 60*10; $need_time_to_load = time()-$load_time; // Должен не читать сообщения из чата 10 минутной давности... $chating = db_read (table_chat,"WHERE msg_time < '$need_time_to_load' ... Еще вопрос. Данный кусок по идее должен не пропускать сообщения, которые старее 10 минут от значения time();. Подскажите, где что не правильно. В БД значение msg_time = time();