Замедления, вызванные малыми задержками
Можно ли проигнорировать небольшие задержки, возникающие при создании новых процессов? Как показано на рис. 16.1, если запрос не требует продолжительной обработки, то значимость таких задержек возрастает.
На этом рисунке приведен пример, в котором затраты времени на обработку запроса меньше, чем затраты времени на создание нового процесса. Обозначим как р время обработки, а буквой с обозначим затраты времени на создание процесса. Предположим, что в момент времени 0 одновременно поступают два запроса. В параллельном сервере обработка первого запроса будет выполнена через cfp единиц времени, а второй запрос будет выполнен через 2с+р единиц времени. Поэтому в этом сервере затраты времени на обработку одного запроса составляют в среднем Зс/2+р единиц времени. В последовательном сервере обработка первого запроса закончится через р, а второго — через 2р единиц времени; таким образом, средние затраты времени на обработку одного запроса составляют Зр/2 единиц времени. Итак, проект последовательного сервера характеризуется более низкой средней задержкой по сравнению с параллельной версией, поскольку для обработки в нем запроса требуется меньше времени, по сравнению с затратами времени на создание процесса. детские велосипеды купить
Небольшая дополнительная задержка может показаться незначительной при рассмотрении лишь нескольких запросов. Однако такая задержка может стать существенной, если рассматривается непрерывная работа сервера под интенсивной нагрузкой. Если большое число запросов поступает примерно в одно и то же время, им приходится ждать, пока сервер не создаст процессы для их обработки. Если дополнительные запросы поступают быстрее, чем сервер может их обработать, задержки увеличиваются.
В ближайшей перспективе, небольшие задержки в сервере влияют на наблюдаемое время отклика, но не на общую производительность. Если пакеты запросов поступают одновременно или почти одновременно, то программное обеспечение протокола, входящее в состав операционной системы, помещает запросы в очередь до того момента, пока сервер не сможет их извлечь и обработать. Например, если в сервере используется транспортный протокол с установлением логического соединения, то программное обеспечение TCP ставит в очередь запросы на установление соединения. Если же в сервере используется транспортный протокол без установления логического соединения, то программное обеспечение UDP ставит в очередь входящие дейтаграммы.
В долгосрочной перспективе, чрезмерные задержки могут вызвать потерю запросов. Чтобы понять, как это происходит, представим себе сервер, которому требуется с единиц времени для создания ведомого процесса, но только р единиц времени (р<с) для обработки запроса. Параллельная реализация сервера позволяет обрабатывать в среднем 1/с запросов за единицу времени, а последовательная версия — 1/р запросов.
Проблема возникает, если скорость поступления запросов превышает 1/с, но остается меньше 1/р. В этом случае последовательная реализация может выдержать нагрузку, а параллельная реализация требует слишком много времени на создание ведомых процессов. В параллельной версии очереди в программном обеспечении протокола в конечном итоге заполняются, и программное обеспечение начинает отбрасывать следующие запросы.
На практике лишь немногие серверы действуют почти на пределе максимальной производительности. Более того, лишь немногие разработчики используют параллельные серверы, если стоимость создания ведомых процессов превышает стоимость обработки. Поэтому во многих приложениях не возникают задержки при обработке запросов и не происходит потеря запросов. Однако в серверах, предназначенных для обеспечения оптимального времени отклика при интенсивной нагрузке, необходимо рассмотреть возможность применения других вариантов по отношению к распараллеливанию с учетом потребностей.