nixp.ru v3.0

23 октября 2017,
понедельник,
14:49:31 MSK

DevOps с компанией «Флант»
Longobard написал 10 августа 2004 года в 15:07 (358 просмотров) Ведет себя как мужчина; открыл 291 тему в форуме, оставил 2499 комментариев на сайте.

Итак в ходе длительного скрипения мозгофф обдумал кучу вариантом организации движка своего веб-сервера. Из них самые лучший вариант имхо такой вот. Какие у вас есть возражения/предложения?

1)main сервера (не обязательно сама ф-я main(), а возможно че-нить вроде ServerMain(), ну не суть вопщем) создает N обьектов vhost (обьекты виртуалхоста), N определено из конфига, каждому из вхостов передаются через аргументы конструктора параметры его, определенные в конфиге. В конструкторе vhost делает форк, итого имеем то что главный процесс сервера имеет N дочерних процессов - vhost-ов.
2) После этого у main есть несколько задач. Это например перечитывать конфиг при получении sighup и через Set...() функции обьектов класса vhost менять их параметры, добавлять/удалять вхосты и т.д. Но основная задача main() - ловить HTTP запросы клиентов, передавать их в сыром виде отдельному процессу (или потоку? что тут посоветуете?), который этот сырой заголовок превращает в обьект класса FL_HTTPRequest, и передает его еще одному процессу/потоку (процесс-координатор так сказать :) ), который отдает этот заголовок соответсвующему вхосту (т.е. берет поле Host заголовка и ищет вхост с таким именет), или говорит клиенту шо заголовок паленый и вежливо посылает клиента нах. Для чего я длать отдельным процессом/потоком координатора и создателя HTTPRequest? Да потому что все эти операции требуют немного времени, за которое при большой нагрузке на сервер main-y прийдет уже куча новых запросов, поэтому это должно ускорить работу сервера.
3)каждый вхост при запуске делает пул из N процессов (N определено в конфиге или дефолт  10). Каждый процесс из пула - это обьект класса FL_PthreadKeeper, который держит пул на F потоков (F в конфиге или дефолт 25 например). Каждый поток занимается обслуживанием клиентов напрямую. Ему через пайп/сокет/очередь мессаг передается дескриптор сокета клиента и HTTP запрос, а пото дальше уже сам обслуживает нещастного клиента. vhost имеет список *потоков*, в которые он сует запрос и дескриптор если поток не обслуживает в данный момент клиента.
Кол-во потоков в вхосте может увеличиватся если клиентов много, увеличивается до заданного в конфиге максимума.  Раз в определенный промежуток времени vhost обходит все имеемые FL_PthreadKeeper, если есть лишние потоки - удаляет. Например есть 5 процессов FL_PthreadKeeper, и 10 потоков в каждом, затем кол-во потоков в каждом растет до максимума (например 25), и создает еще два FL_PthreadKeeper и т.д. потом клиенты свалили, зачем тогда держать такой зоопарк? vhost прибивает лишние процессы. Но всегда остается один запасной незаняый FL_PthreadKeeper, который создан чтобы быстро реагировать на вновь прибывших клиентов, а не тратить время на создание процесса. Если в FL_PthreadKeeper занятых потоков остается менише половины минимума, то они передаются другому вхосту и этот FL_PthreadKeeper убивается.

Что подскажите заюзать для координатора и парсера запросов — поток или процесс? Через что лучше передавать запросы и дескрипторы — через пайпы, UNIX-сокеты или через двери илиочереди сообщений?

myst

Тебе design pattern «Observer» заюзать было бы хорошо, наверное.

Longobard
myst
Тебе design pattern «Observer» заюзать было бы хорошо, наверное.

?

myst
Longobard

А что подскажете юзать для парсера запросов и координатора? процесс или поток?