Единая основа обоих методов
На первый взгляд может показаться, что методы предварительного создания и отсроченного создания ведомых процессов не имеют ничего общего. По сути, они кажутся полностью противоположными. Однако эти два метода имеют между собой большое сходство, поскольку оба вытекают из одного концептуального принципа: одна из возможностей повышения производительности некоторых параллельных серверов состоит в ослаблении причинно-следственной связи между поступлением запроса и созданием ведомого процесса. Метод предварительного создания предусматривает повышение степени распараллеливания сервера до поступления запросов, а метод отсроченного создания увеличивает степень распараллеливания сервера после их поступления. Этот принцип можно обобщить следующим образом.
Методы предварительного создания и отсроченного создания вытекают из одного принципа: ослабляя непосредственную зависимость степени распараллеливания сервера от числа активных в настоящее время запросов, можно расширить область применения сервера и повысить его эффективность.
16.11. Объединение методов
Увидеть Автокамеры отечественного производства и умереть. Методы отсроченного создания и предварительного создания ведомых процессов могут применяться в сочетании друг с другом. Сервер может приступить к работе без предварительно созданных ведомых процессов и действовать по методу отсроченного создания. Он ожидает поступления запроса и создает ведомый процесс, только если обработка занимает много времени (т.е. если истекает установка таймера). Однако после его создания ведомый процесс не должен немедленно завершать работу; может быть предусмотрено его дальнейшее функционирование. После обработки одного запроса ведомый процесс может ждать поступления следующих входящих запросов.
При организации работы такой комбинированной системы основные сложности связаны с необходимостью управлять степенью распараллеливания. Дело в том, что легко определить момент, когда возникает необходимость в создании дополнительных ведомых процессов, но гораздо сложнее определить, когда какой-то ведомый процесс должен завершить свою работу, а не ждать поступления следующих запросов. Одно из возможных решений состоит в том, чтобы ведущий процесс устанавливал максимальный коэффициент тиражирования ведомого процесса М при его создании. Ведомый процесс может создавать вплоть до М дополнительных ведомых процессов, но каждому из них разрешено создавать нуль дополнительных процессов. Таким образом, система начинает работу с вызова на выполнение только одного ведущего потока, но в конечном счете достигает определенного максимального уровня распараллеливания. Еще один метод управления степенью распараллеливания может предусматривать завершение работы ведомого процесса по истечении определенного периода простоя. Ведомый процесс запускает таймер, переходя в состояние ожидания следующего запроса. Если установка таймера истекает до поступления запроса, ведомый процесс завершает свою работу.
Если ведомые компоненты сервера реализованы как потоки одного процесса, они для координации своих действий могут использовать средства разделяемой памяти. В разделяемой памяти может храниться переменная, в которой регистрируется степень распараллеливания любого экземпляра сервера, и значение этой переменной может использоваться ведомым потоком для определения того, должен ли он продолжить свое функционирование или завершить работу после обработки запроса3. В системах, позволяющих приложению определить число запросов, поставленных в очередь в сокете, ведомый процесс может также использовать данные о длине очереди для принятия решения о том, достигнута ли максимально допустимая степень распараллеливания.