Re: Функционал и интерфейс
В Вто, 17/03/2009 в 22:49 +0300, Alexey Pechnikov пишет:
> Hello!
>
> On Tuesday 17 March 2009 22:19:12 Покотиленко Костик wrote:
> > Если изменить архитектуру так:
> > - один процесс принимает все соединения с одной стороны, и общается с
> > несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
> > количестве равном количеству ядер
> > - процессы выполняющие вычисления читают данные через процессы работы с
> > дисками (по одному на каждый физический диск), выполняют обработку,
> > отдают результат главному, тот клиенту
> > - процессы работы с дисками обрабатывают чтение запись и всё.
> >
> > С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
> > клиентов будет 7 процессов.
>
> И что, "магическое" число 7 принесет удачу серверу? :-)
>
> Предложенная вами архитектура не годится. Хотя бы потому, что 1 "слушающий"
> процесс всегда будет "узким местом".
Не будет. Его задача состоит только в том чтобы делать read() на сокет
клиенты и write() на сокет процесса выполняющего вычисления, потом
обратно, и так по кругу для всех клиентов. Нагрузка около нуля.
> Далее, операции чтения с диска могут
> выполняться параллельно многими процессами (есть кэш диска плюс кэш
> операционной системы). И для записи даже для SATA-диска размер очереди команд,
> равный 1, далеко не оптимум, а для SAS дисков тем более.
Вопрос конечно спорный. Скажу только, что если не принимать во внимание
кэш ФС то в один момент времени один винт может обрабатывать равно один
запрос, поэтому чтение одним процессом может быть производительнее,
особенно если его очередь постарается сделать чтение более
последовательным.
Насчёт кэша. Как вариант можно делать несколько процессов на диск, или
кэшировать прям в процессе.
Хотя стой, не надо плодить процессы и встраивать кэш. В любом случае
один процесс читающий последовательно будет не медленее чем два
параллельно. Кэш ФС тут помощник как в первом случае так и во втором.
Если я не прав, давайте обсудим.
> А еще есть рэйд-
> контроллеры, которые дополнительно оптимизируют дисковые операции, в т.ч. за
> счет своего кэша.
Ну, если нужен рэйд, кто мешает.
> Не говоря уже о бессмысленности создания "бутылочного горла"
> между читающими и вычисляющими процессами.
Не знаю, на сколько это узкое горло, но если перейти от сокетов/пайпов к
общей памяти или от процессов к нитям с общей памятью, этот вопрос точно
отпадёт.
> Не пытайтесь угадать - чтобы
> создать эффективную архитектуру, нужно знать теорию и уметь ее применять. А уж
> что касается работы с оборудованием, так тут еще требуется набор неочевидных
> компромиссов, если необходимо обеспечить поддержку, к примеру, разных типов
> дисков.
Я не пытаюсь угадать, я пытаюсь размышлять.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: