В Вто, 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 процессов. -- Покотиленко Костик <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
