Применение метода предварительного создания в многопроцессорной системе
Метод предварительного создания в многопроцессорной системе имеет особое значение. Он позволяет разработчику согласовать степень распараллеливания в сервере с возможностями аппаратных средств. Если на компьютере установлено К процессоров, то разработчик может предусмотреть предварительное создание К ведомых процессов. Поскольку многопроцессорные операционные системы назначают каждому ведомому процессу отдельный процессор, метод предварительного создания обеспечивает согласование степени распараллеливания с возможностями аппаратного обеспечения. После поступления запроса операционная система передает его одному из предварительно созданных ведомых процессов и назначает этому процессу один из процессоров. Поскольку ведомый процесс уже был предварительно создан, то для его запуска не требуется много времени. Поэтому операционная система может быстро передавать запросы на выполнение. При поступлении пакета запросов каждый процессор обрабатывает один запрос, что приводит к достижению максимально возможного быстродействия.
Отсроченное создание ведомых процессов
Хотя метод предварительного создания способствует повышению эффективности, он не решает всех проблем. Любопытно то, что при некоторых обстоятельствах эффективность работы можно повысить с использованием противоположного подхода, а именно метода отсроченного создания ведомых процессов.
Чтобы понять, почему может возникнуть необходимость отложить создание ведомых процессов, следует вспомнить, что создание ведомого процесса требует времени и ресурсов, и поэтому может быть оправдано только в том случае, если приведет к некоторому повышению производительности системы или к уменьшению задержки. Создание ведомого процесса не только требует времени, но и порождает дополнительную нагрузку на те компоненты операционной системы, которые должны управлять еще одним процессом или потоком. Кроме того, предварительное создание нескольких ведомых процессов, предпринимающих попытки получения входящих запросов, может увеличить нагрузку сетевого программного обеспечения.
Как уже было сказано выше, распараллеливание позволяет уменьшить задержку только в том случае, если затраты на создание ведомого процесса меньше по сравнению с затратами на обработку запроса. Если стоимость обработки запроса ниже, то последовательное решение является более целесообразным. Однако не всегда есть возможность определить, какие из этих затрат будут меньше, поскольку затраты часто зависят от самого запроса (например, от содержания запроса зависит продолжительность поиска в базе данных).
Кроме того, необходимо учитывать вероятность обнаружения ошибки в запросе. Чтобы понять, с чем это связано, рассмотрим, как работает основная часть серверного программного обеспечения. Сразу после поступления запроса серверная программа проверяет сообщение для определения того, содержат ли все его поля допустимые значения, и имеет ли клиент право присылать запрос. Проверка может потребовать лишь несколько микросекунд или может повлечь за собой дополнительный обмен данными по сети, который займет значительно больше времени. С одной стороны, если сервер обнаружит ошибку в сообщении, он быстро отклонит этот запрос, в результате чего общие затраты времени на обработку сообщений будут настолько малы, что ими вполне можно пренебречь. С другой стороны, если сервер получит допустимый запрос, то на его обработку может уже потребоваться значительное время. В тех случаях, если время обработки невелико, параллельная обработка не оправдана; последовательный сервер характеризуется меньшей задержкой и более высокой производительностью.
Как могут разработчики оптимизировать задержку и производительность, не зная, при каких обстоятельствах будет оправдана параллельная обработка? Ответом может служить применение метода отсроченного создания ведомых процессов. В основе этого метода лежит простой принцип: вместо выбора последовательного или параллельного проекта необходимо предусмотреть в сервере измерение стоимости обработки и принятие решения о переходе к последовательной обработке или параллельной обработке в зависимости от полученных результатов. Переход от одного режима к другому происходит динамически, поскольку ситуация изменяется от одного запроса к другому.
Для реализации динамического метода отсроченного создания ведомых процессов в серверах обычно предусматривается оценка стоимости обработки путем измерения затрат времени. Ведущий сервер получает запрос, устанавливает таймер и приступает к последовательной обработке запроса. Если сервер завершает обработку запроса до истечения установки таймера, то сервер сбрасывает таймер. Если установка таймера истекает до того, как сервер заканчивает обработку запроса, сервер создает ведомый процесс и позволяет ему продолжить обработку запроса.
При использовании метода отсроченного создания ведомых процессов сервер вначале приступает к последовательной обработке каждого запроса и создает параллельный ведомый процесс для обработки конкретного запроса, только если его обработка требует значительных затрат времени. Поскольку создание ведомого процесса откладывается, это позволяет ведущему процессу проверять ошибки и обрабатывать короткие запросы, прежде чем появится необходимость создать ведомый процесс или переключить контекст.
В системе Linux метод отсроченного создания ведомых процессов реализуется очень просто. Поскольку в этой системе предусмотрен сигнальный механизм, ведущий поток может установить таймер и предусмотреть выполнение определенной процедуры по истечении установки таймера. Поскольку функция fork системы Linux скайп для андроид позволяет вновь созданному процессу унаследовать открытые сокеты, а также копию выполняемой программы и данных от родительского процесса, то ведущий процесс может создать ведомый процесс, который продолжит обработку именно с той точки программы, в какой находился ведущий процесс в момент истечения установки таймера.