Re: Функционал и интерфейс
Hello!
On Tuesday 17 March 2009 22:19:12 Покотиленко Костик wrote:
> Если изменить архитектуру так:
> - один процесс принимает все соединения с одной стороны, и общается с
> несколькими процессами выполняющими вычисления (SSI, PHP, etc) в
> количестве равном количеству ядер
> - процессы выполняющие вычисления читают данные через процессы работы с
> дисками (по одному на каждый физический диск), выполняют обработку,
> отдают результат главному, тот клиенту
> - процессы работы с дисками обрабатывают чтение запись и всё.
>
> С такой архитектурой на 4-х ядрах и 2-х винчестерах при любом количестве
> клиентов будет 7 процессов.
И что, "магическое" число 7 принесет удачу серверу? :-)
Предложенная вами архитектура не годится. Хотя бы потому, что 1 "слушающий"
процесс всегда будет "узким местом". Далее, операции чтения с диска могут
выполняться параллельно многими процессами (есть кэш диска плюс кэш
операционной системы). И для записи даже для SATA-диска размер очереди команд,
равный 1, далеко не оптимум, а для SAS дисков тем более. А еще есть рэйд-
контроллеры, которые дополнительно оптимизируют дисковые операции, в т.ч. за
счет своего кэша. Не говоря уже о бессмысленности создания "бутылочного горла"
между читающими и вычисляющими процессами. Не пытайтесь угадать - чтобы
создать эффективную архитектуру, нужно знать теорию и уметь ее применять. А уж
что касается работы с оборудованием, так тут еще требуется набор неочевидных
компромиссов, если необходимо обеспечить поддержку, к примеру, разных типов
дисков.
На практике потребуется пул процессов для обработки запросов и очередь (чтобы
не создавать слишком много процессов обработки в "пике" нагрузки), а для
выполнения блокирующих/потенциально опасных операций и длительных вычислений
отдельные пулы внешних процессов (например, пулы соединений с БД) - так, в
частности, работает AOL Server.
Best regards.
Reply to: