отдельный сервер под чат

[mam0n]

отдельный сервер под чат

Здра, программеры.
Дело в том, что хотел бы купить под чат отдельный сервер. Стоит ли писать демон на с++, для вывода сообщений, или же можно обойтись простым пхп-скриптом, с бесконечным циклом, который бы для каждого онлайн юзера открывал бы отдельный процесс, т.е. даже не демон.
В распоряжении довольно мощный сервер. Чат на mysql. Структура БД оптимизирована.

На самом деле хотел бы выбрать 2 вариант )) Но рассчитываю на 1000 онлайн пользователей, а может получиться и больше.

Что выбрать?
Сколько будет стоить написать демона на си++?

 

[voodoo]

Апач + бесконечный скрипт в чайлде (пхп или перл) в тех реализациях что я видел заваливали сервер примерно одинаково, при ~150 пользователях онлайн двухголовый п3-800 уже совсем умирал. Сейчас конечно процессоры побыстрее а память побольше, но думаю что больше 300 все равно никак не выйдет.

Кроме того, еще и апач (если его планируется использовать) придется пересобирать, там ограничение в 256 чайлдов.

 

[Krishna]

mam0n
Если бы мне случилось необходимым решать такую задачу, я бы сначала реализовал чат на php, утвердив необходимые интерфейсы, дизайн и функциональность. Далее, протестировав полученный скрипт на производительность при максимальной оптимизайии (nignx, eaccelerator, etc...) я бы уже принимал решение о переходе на C. Мне кажется переписать на C уже имеющееся решение было бы проще + если PHP вариант (разработка которого, по идее должна занимать заметно меньше времени) показал бы удовлетворительные результаты - можно было бы сэкономить время необходимое для разработки на C++.

Выше сказанное сугубо моё ИМХО.

 

[mam0n]

Дамм, пхп не катит. Сколько времени займет написание демона на си у одного человека под линкус и сколько это будет стоить, хотя бы примерно?

А если использовать демон на пхп, сколько можно посадить народа в чат? Не особо понимаю как это реализуется, ни разу это не делал, но как то слышал, что так можно сделать.

 

[Krishna]

[deleted]
Пардон, был нетрезв =)

 

[Paxan]

Чат на mysql

имхо дёргать базу каждый раз не совсем разумно, можно посмотреть в сторону shared memory.

можно еще посмотреть по поводу готовых реализаций:
http://vochat.com/ - готовые демоны на перл и с++
http://chat.php.spb.ru/ - демон на tcl, не опен сорс.

 

[ONK]

mam0n, если сервер чата грамотно написан на ПХП, он по производительности уступит серверу на С всего в несколько раз. И это не будет принципиально важно, т.к. грамотно написанный сервер это не самое узкое место чата.

 

[fisher]

>>всего в несколько раз
а это мало?

>>грамотно написанный сервер это не самое узкое место чата
а что узкое?
я без "ха", чистый интерес

 

[voodoo]

вообще, интересно было бы сравнить хорошие реализации на ПХП и С.

Из моего опыта (непрофессионального, поскольку пхп, перл и с сейчас я занимаюсь исключительно дома), Перл-демон проигрывал в 10-15 раз с-демону по cpu-usage. Т.е., скажем, при 300 посетителях разница в 5% цпу и 75% (на п4-2400МГц). Это просто гнездец как много, с учетом выбранной схемы (демон только для отдачи сообщений), когда остается еще куча пхп-скриптов для обработки всего остального, напр. для парсинга сообщений, выдачи списка пользователей и тому подобной вспомогательной информации.
Демон на ПХП не пробовал, т.к. когда все это делал, необходимые ПХП-расширения были в статусе "Experimtental".
Может, конечно, перл-версия совсем плохая, тогда было бы интересно сравнить с правильным пхп-демоном. Но думаю что будет примерно то же самое.

---
тема 2.
реализация всего на пхп и потом переписывание на с может выйти боком.
В случае ПХП-скриптов (один скрипт на клиента/процесс) необходимо место для хранения и обмена динамическими данными (онлайн-пользователи, актуальные сообщения и т.п.). В итоге получим борьбу за доступ к файлу (базе/блоку в памяти).
В случае полнофункционального демона (т.е. который делает все, не только отдачу сообщений) можно всю информацию хранить в памяти (и несколько тредов будут будут просто читать/записывать в общем пространстве). Понятно, нужны всякие мутексы, но все равно должно получиться очень интересно.
Проблема же в том что эти две реализации очень разные, т.е. фактически придется переписывать все.

--
ну а завтра я тоже напишу "был нетрезв"

 

[ONK]

fisher, узким местом будут скрипты ПХП принимающие HTTP запросы от браузеров пользователей. Соотношение нагрузки ПХП сервер : обрабатывающие скрипты ~1:100 - 1000 (зависит от самих скриптов и использования средств кэширования опкода).

voodoo, сервер форкающий потомков на скриптовом языке по понятным причинам никогда не будет эффективен. А вот если сравнить сервер написанный на С (С++) форкающий потомков и сервер написанный на ПХП, эмулирующий многопоточность внутри одного процесса, неизвестно кто окажется быстрее, а тем более экономичнее по оперативной памяти.

Идея один процесс на каждого клиента, для скриптового языка изначально выглядит не жизнеспособной, такую конструкцию даже рассматривать не стоит.

-~{}~ 09.07.06 16:48:

>>всего в несколько раз
а это мало?

Это мало, надо учитывать что "чистый" ПХП код исполняются ~ в 1000 раз медленнее чем аналогичный набор процессорных инструкций. А если добавить накладные расходы на загрузку, компиляцию и запуск ПХП скриптов, то всё ещё хуже (в случае с демоном это можно не учитывать).

 

[voodoo]

непонятно только зачем в случае чата нужен сервер на с форкающий потомков. явно появляются ненужные доп. расходы.
Достаточно одного процесса и select

ONK, я так понимаю что у тебя есть уже такой чат с пхп-демоном. Можешь сказать примерные цифры (цпу, память) для него при 100,200,300,400,500 пользователей онлайн? (толкьо цпу не из ps а из top), ну и немножко инфы о сервере (какой проц) и о демоне (бесконечный цикл с паузами? и как берет новые сообщения -- файлы/база/память)?

 

[ONK]

voodoo, чат такой есть, но уже 1,5 года нету времени им заниматься, поэтому из требуемых данных могу лишь привести потребление оперативной памяти 7,5мб + 3кб*n где n - количество пользователей в чате. Потребление процессорных ресурсов пренебрежимо мало (на фоне служебных скриптов, обслуживающих HTTP запросы).
Демон состоит из двух взаимно вложенных бесконечных цикла. 1-й блокирующий "командный цикл", служит для управления демоном и раздачи команд подключённым клиентам. Второй не блокирующий цикл на приём подключений новых клиентов. Где-то между ними обработка стека не блокирующих сокетов с целью раздачи команд подключенным клиентам. Обмен данными и командами по командному сокету. Это очень краткое описание текущей версии.

 

[fisher]

>> ПХП принимающие HTTP запросы от браузеров пользователей
а, это понятно - но вот cкажем промелькнули цифры что 300 юзеров онлайн это 5% CPU для сишного демона и ну пусть 15% (разы) для скриптового. прекрасно, а если нам надо 5000 юзеров онлайн? да, на малых нагрузках упремся сначала в интерфейсные штуки, все верно, но пхп-шные интерфейс к чату как два пальца можно разносить на разные тачки при большой нагрузке в то время как сервер разнести задача совсем нетривиальная и поскольку разнося пхп ты масштабируешься почти линейно - рано или поздно "десять раз" на сервере это уже будет совсем не смешно, все будет определяться именно быстродействием сервера впрочем, это все скорее всего касается не обычных чатов, а либо очень популярных чатов, либо чатов с более хитрой бизнес-логикой. но тем не менее, это я все к чему - писать серверы на пхп под приличную нагрузку лучше даже не пытаться имхо.

2voodoo: влад вострых - это вы?

 

[ONK]

fisher, к сожалению я не могу привести реальные цифры, но мои тесты позволяют мне предположить, что при 300 пользователях онлайн (среднестатистической активности), демон ПХП сервера будет создавать нагрузку какраз около 3 - 5% для П4 2.4ГГц (хотя реально её достигнуть не удастся). По моим тестам, распределение процессорных ресурсов было в районе 1:100 демон:скрипты обработки HTTP запросов. Так что предел эффективного масштабирования серверов обработки запросов до 50% нагрузки не менее 50 процессоров.

-~{}~ 10.07.06 00:04:

voodoo, как я понимаю, у тебя демон имеет бесконечный цикл с паузами? Как осуществляется обмен данными?

 

[stiff]

А нельзя завязать все на чтото вроде ircd?

 

[voodoo]

Проблема в том что цпу-юзадж растет, по идее, совсем не линейно от количества пользователей.
Просто в каждом цикле нам надо пройтись по всем пользователям, и для каждого пользователя еще пройтись по всем сообщениям (для отправки и каких-либо проверок, напр. приватное сообщение или отправитель в игноре).
При этом кол-во отправляемых сообщений обычно прямо пропорционально кол-ву онлайн пользователей (это из статистики, напр. http://vochat.com/statdemo.html )
т.е. получаем квадрат от кол-ва онлайн пользователей.
Поэтому перл-демон, казавшийся мне удачным при 50-100 пользователях, при 300 стал работать с большим скрипом. Вот и интересно было бы посмотреть на другие реализации в реальных инсталляциях.

ответы на вопросы
ONK, да. Сейчас оно умеет работать с MySQL, файлами и SHM.
Вообще я думаю о версии когда все данные будет держать демон у себя в памяти, пхп остается для, напр., для обработки входящего сообщения (ну там расцвечиваем, например, или картинки вставляем), и потом отдает это демону (через unix-sockets, например). Ну и там можно будет вообще убрать циклы и паузы -- повесить отдельный тред для отдачи сообщений в pthread_cond_wait (а можно по треду на комнату, надо подумать). Правда непонятно нужно это кому-то или получится как всегда

fisher, я
А разнести демона по серверам можно, например, по комнатам.
Т.е. сервер1 занимается только комнатами 1-2-3, а сервер 2 -- комнатами 4-5-6.
При переходе с сервера на сервер дергать какой-нибудь внутренний скрипт, для переноса данных пользователя (т.е. локально все держать).

А можно вообще из базы все брать, тогда и менять ничего не надо (если только база справится)

 

[ONK]

voodoo, теперь понятно почему у тебя такая нагрузка на С++ демоне всего при 300 юзерах.
Цикл с таймаутом это не очень эффективное решение (если таймаут не меняется динамически по необходимости). У меня для оптимизации производительности все действия, которые можно произвести скриптами обработки HTTP запосов, выполняются именно ими. Сервер получает по командному сокету структуру тапа {список пользователей:команда[:аргументы]....}.
Получается, что рост нагрузки создаваемый демоном линеен.

Есть у меня ещё пара мыслей по оптимизации, будет порыв энтузиазма, может напишу новую версию сервера.

ПС. Допустим, пользователь одновременно находится в нескольких комнатах, тут сервер масштабировать не удастся (или это будет изврат с удержанием нескольких соединений браузером, состояние каждого из них придётся отслеживать), но это и ненужно, нагрузка демона реально пренебрежимо мала относительно остальных компонентов чата (речь идёт о моей схеме).

 

[voodoo]

ну цифры-то я так, примерно сказал.
сейчас вот 406 онлайн, цпу на демона -- 1.0-2.0% (все тот же п4-2.4)

в общем примерно все понятно, вопросов (пока) больше нет