мы не форкались, но активно использовали сокеты. как показал наш опыт — утечки связаны с кодом, а не с языком — наверняка есть циклические ссылки, например.
совет по отлову — логируйте сколько было памяти до обработки запроса и после. если дельта больше нуля — смотрите всю цепочку обработки, удаляйте не нужные объекты, избавляйтесь от циклических ссылок. особое внимание — foreach'ам с объектами.
мы используем другой подход code.google.com/p/pha-yii-author/ — авторская конфигурация.
плюсы:
— каждый разработчик/инсталяция может имет собственный конфиг (со всеми штатными возможностями наследования)
— для подключения нет необходимости вносить изменения в код (index.php) — нужный конфиг подключается автоматически, стоит создать соответствующий пустой файл (соответствующая директория добавляется в игнор в системе контроля версий).
— поскольку конфиг у кажого свой разработчки может не бояться поломать общий файл, подключать в свем конфиге различные экспериментальные фичи
как ставить/подключать описано на форуме www.yiiframework.ru/forum/viewtopic.php?f=9&t=2479&p=15258
наши демоны на связке php+libevent способны были держать несколько тысяч в онлайне. 100 тысяч — это десяток серверов, совсем не много. доходы от игры, где 100 тыс в онлайне, позволят сделать корпуса таких серверов из золота ;) технически сделать не так сложно, гораздо сложнее этих 100 тысяч привлечь и удержать.
а поддержка/отладка + развитие кода такой же игры на С++ обойдется гораздо дороже.
у нас была mmorpg. однопоточный демон вполне способен был держать до нескольких тысяч человек в онлайне (демон боев — может чуть меньше), далее — мы закладывали баллансировку нагрузки по идентичным демонам (например, когда бы демон локаций перестал бы справляться — подняли бы второго и часть локаций обслуживал бы уже новый). а необходимость форкаться — это следствие выбранной архитектуры, для реализаций игр, исходя из нашей практики, она не нужна.
зачем орм в таких проектах?? если течет доктрина, почему пишите, что течет РНР?
и вообще — есть ли реальная необходимость форкаться? нам производительности однопоточного демона вполне хватало даже на обсчет боев. к тому же форк не позволяет воспользоваться преимуществом использования уже готовых объектов, которые не нужно инициализировать. мы вообще в базу ходили фактически только при логине нового игрока, да когда сохраняли состояния измененных объектов (раз в N минут).
расставить unset, заменить все foreach, отслеживать циклические ссылки, логировать память при всех созданиях и уничтожениях объектов (сколько пришло — столько ушло). и бить разработчикам по рукам, если они не делают этого. при соблюдении таких не хитрых техник все течи исчезнут.
проверено — демоны на либевенте не текут (ничего не могу говорить за phpDaemon, мы делали сами свою реализацию).
1. До запуска Скалакси было офигенное кол-во конференций, на которых, в том числе и Дима, довольно подробно рассказывали об архитектуре. то что прошло очень много времени от раскрытия архитектуры до реального запуска Скалакси и что за это время можно было построить работающую систему — явно не проблема Клодо.
2. То что пишет Дима, надо заметить не в своем, а корпоративном блоге — это его личное мнение и только. Если было бы иначе — есть суды, есть закон о коммерческой тайне, как умеет судится Оверсан все знают. Но, на сколько я знаю, никаких реальных доказательств слива нет — только логические выводы. Собственно поэтому наверное и исков нет.
3. Похожесть панелей очень относительная. Они похожи только в общих, очевидных подходах. Кстати доступ к интерфейсам панели был далеко не у всех. А так чтоб и к описании архитектуры и к интерфейсам — так вообще у единиц. Большая часть из которых были руководители.
4. Мне кажется естественным возникновение вопроса о том, откуда такие знания о конкуренте? Мне кажется, что в отличии от, Клодо так активно не участвовало в конференциях и не раскрывало столь подробно свою архитектуру.
Еще раз повторюсь — никто из ключевых сотрудников не уходил из Скалакси в обсуждаемый период (когда передача данных могла бы дать преимущество).
более того, могу утверждать, что до определенного момента никто из ключевых сотрудников оверсана не уходил. а после ухода тех, кто теоретически мог бы что-то «слить» — у клодо просто не хватило бы времени воспользоваться
2 панели могли были существовать только в голвах определенных людей. технически — пананель всегда была одна.
документация по панели _всегда_ была актуальна более чем на 90%. оставшиеся % — легко актуализировалось благодаря автоматической генерации документации по коду.
ТЗ на панель макхоста действиетльно ох… й документ. только совсем не в том смысле, что использовано в письме.
совет по отлову — логируйте сколько было памяти до обработки запроса и после. если дельта больше нуля — смотрите всю цепочку обработки, удаляйте не нужные объекты, избавляйтесь от циклических ссылок. особое внимание — foreach'ам с объектами.
плюсы:
— каждый разработчик/инсталяция может имет собственный конфиг (со всеми штатными возможностями наследования)
— для подключения нет необходимости вносить изменения в код (index.php) — нужный конфиг подключается автоматически, стоит создать соответствующий пустой файл (соответствующая директория добавляется в игнор в системе контроля версий).
— поскольку конфиг у кажого свой разработчки может не бояться поломать общий файл, подключать в свем конфиге различные экспериментальные фичи
как ставить/подключать описано на форуме www.yiiframework.ru/forum/viewtopic.php?f=9&t=2479&p=15258
а поддержка/отладка + развитие кода такой же игры на С++ обойдется гораздо дороже.
и вообще — есть ли реальная необходимость форкаться? нам производительности однопоточного демона вполне хватало даже на обсчет боев. к тому же форк не позволяет воспользоваться преимуществом использования уже готовых объектов, которые не нужно инициализировать. мы вообще в базу ходили фактически только при логине нового игрока, да когда сохраняли состояния измененных объектов (раз в N минут).
проверено — демоны на либевенте не текут (ничего не могу говорить за phpDaemon, мы делали сами свою реализацию).
2. То что пишет Дима, надо заметить не в своем, а корпоративном блоге — это его личное мнение и только. Если было бы иначе — есть суды, есть закон о коммерческой тайне, как умеет судится Оверсан все знают. Но, на сколько я знаю, никаких реальных доказательств слива нет — только логические выводы. Собственно поэтому наверное и исков нет.
3. Похожесть панелей очень относительная. Они похожи только в общих, очевидных подходах. Кстати доступ к интерфейсам панели был далеко не у всех. А так чтоб и к описании архитектуры и к интерфейсам — так вообще у единиц. Большая часть из которых были руководители.
4. Мне кажется естественным возникновение вопроса о том, откуда такие знания о конкуренте? Мне кажется, что в отличии от, Клодо так активно не участвовало в конференциях и не раскрывало столь подробно свою архитектуру.
Еще раз повторюсь — никто из ключевых сотрудников не уходил из Скалакси в обсуждаемый период (когда передача данных могла бы дать преимущество).
документация по панели _всегда_ была актуальна более чем на 90%. оставшиеся % — легко актуализировалось благодаря автоматической генерации документации по коду.
ТЗ на панель макхоста действиетльно ох… й документ. только совсем не в том смысле, что использовано в письме.