Мультитредовое ядро. Проблемы использования и реализации.

[Alexandre]

sivirk извини, у меня что-то с терминологией...
как понял я:

запускается демон и затем уже он запускает n вокеров

есть родительский процесс, который запускает n дочерних процессов.

один из которых предсталяет UDP сокет сервер.

один дочерний процесс представляет UDP сокет сервер, т.е. слушает UDP сокет.

Все вокеры, включая и сокет сервер соединены с Демоном парными сокетами.

все дочерние процессы общаются с родительским через сокеты (я так понимаю юникс сокетами )

При поступлении запроса на сокетный вокер он отправляет его на Ноду (демон), а тот в свою очередь отправляет его на свободный вокер

Понятно, что-то типа pre-fork архитектуры.

где запрос выполняется и отправляется ответ.

ответ, я так понимаю отправляет UDP сервер. т.е. дочерний процесс ответ гонит на родительский, а тот отправляет его на UDP сервер.

А что, делает сам дочерний процесс (вокер) - обращается к БД, + кеширование ответа. какова его логика?
почему используем UDP? или это особенность приложения.
почему слушатель - вокер, а не сам родительский процесс? зачем лишний раз нагружать сокеты, это ограниченный ресурс.

 

[sivirk]

Вокер действительно обращается к БД и.т. то е сть осуществляет непосредственно логику процесса и частично занимается кешированием, пока что через мемкэш.
UDP - потому что они быстрее и есть ряд обстоятельств связанный со спецификой работы сокетов в фре.
разделили же в виду того что `слушатель` и нода(родительский процесс) достаточно сильно различаются по назначению

 

[Alexandre]

sivirkкак я понял, все остальные процессы выполняют один и тот же функционал.

UDP - потому что они быстрее и есть ряд обстоятельств связанный со спецификой работы сокетов в фре.
разделили же в виду того что `слушатель` и нода(родительский процесс) достаточно сильно различаются по назначению

мне кажется, что вполне нормальная логика:
- Нода - порождает pre-fork процессы, устанавливает связь с дочерьми
- Далее Нода начинает слушать UDP и в случае прихода запроса, передавать этот запрос на свободный вокер и снова входить в процесс прослушки.
- если запрос выполнился, вокер отправляет по сокету данные на Ноду, а нода отдает их клиенту...
мне кажется так логичнее.

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

ИМХО, я бы применил типовой TCP(UDP) сервер fork архитектуры на Си. Примеров полно. чесс слово - меньше проблем будет с памятью да и интереснее.
мы тоже хотели кеширующего демона писать на пхп, потом я отговорил руководство, на Си заняло 1 мес (на пхп я бы сделал за неделю )

-~{}~ 13.02.08 14:01:

нода(родительский процесс) достаточно сильно различаются по назначению

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

 

[sivirk]

Нода проверяет на возможность выполнения запроса на данном сервере.
Предполагается что в будущем демона на си писать. В данный момент задача функционал сделать, а коим образом это будет упралятся, т.е. реализация ноды и вокеров, не должны влиять на непосредственно модули программы

 

[Alexandre]

еще пара вопросов:
это как-то с WEB связано, какая задача решается?
что должно управляться...

одно понятно, решение временное, данный сервер будет переписан на си.

на мой взгляд - нода должна минимум логики иметь, т.к на нее ложится задача коммуникации.

 

[sivirk]

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

 

[Alexandre]

какова предполагаемая нагрузка приложения ?
зачем все-таки решили демона?
что -mysql_proxy не справляется?
почему все-таки UDP?

я так понял - само ядро - живет отдельно от WEB приложения?
как WEB приложение общается с демоном?
каково время отклика демона?
есттьли функциональная нагрузка (заложена ли какая-либо Модель) в дочерние процессы
или они только играют роль между БД и центральным процессом (Нодой)