Re: Функционал и интерфейс
В Вто, 17/03/2009 в 21:38 +0300, Alexey Pechnikov пишет:
> Hello!
>
> On Tuesday 17 March 2009 21:14:37 Покотиленко Костик wrote:
> > > Есть у меня и демоны на тикле, например, собирают и обрабатывают данные с
> > > цисок и других АТС. Написать то же самое на С большая работа (на тикле
> > > используются события для прослушивания множества сокетов, а на С придется
> > > создавать отдельные потоки),
> >
> > Кто тебе такое сказал? Если за последнюю пару лет ничего не изменилось
> > то в Линуксе осталось несколько ситуаций блокирующих программу, это
> > работа с диском и штатный DNS резолвинг, может ещё чего.
> >
> > А работа с пайпами и сокетами в любом количестве сто лет может
> > производиться без блокировок одним процессом.
>
> "Между теорией на практикой в теории нет никакой разницы, а на практике -
> наоборот".
> Тот же apache вовсе не случайно для каждого соединения отдельный
> поток создает. Так что сначала попробуйте, прежде чем советовать.
Ничего случайно не бывает.
В случае с apache, на мой взгляд, дело в архитектуре.
Грубо говоря, Apache с одной стороны читает с диска, с другой пишет с
сокет. Работа с сокетом может производиться без блокировок, с диском
нет, следовательно один процесс много клиентов не потянет, начнутся
лаги. С другой стороны только один процесс может слушать порт (80), он
может делать accept() и потом fork() передавая установленное соединение
потомку. Ждать 5 соединений и потом делать fork() не вариант.
Если изменить архитектуру так:
- один процесс принимает все соединения с одной стороны, и общается с
несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
количестве равном количеству ядер
- процессы выполняющие вычисления читают данные через процессы работы с
дисками (по одному на каждый физический диск), выполняют обработку,
отдают результат главному, тот клиенту
- процессы работы с дисками обрабатывают чтение запись и всё.
С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
клиентов будет 7 процессов.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: