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.