Архитектура серверов с управлением по событиям

Простейшим подходом является сервер с единственным процессом, который обслуживает один запрос за раз. Процесс принимает клиентский запрос, генерирует и передает ответ клиенту, после чего переходит к следующему запросу. Естественным расширением для Web-сервера, обрабатывающего запросы в одном процессе, является переключение с одного обрабатываемого запроса на другой. Вместо того чтобы обработать запрос с начала до конца, процесс периодически выполняет небольшую часть работы для каждого обрабатываемого запроса. Подобный нодход с управлением по событиям наиболее приемлем в тех случаях, когда каждый запрос требует небольшого объема работы. Обработка Web-запроса легко подразделяется на небольшое количество действий: соединение с клиентом, чтение HTTP-запроса, нахождение соответствующего ресурса и передача ответа. Во многих случаях сервер может завершить каждое из этих действий за короткий период времени.

Однако некоторые из этих действий могут породить задержки, неподконтрольные Web-серверу. Например, сервер не может пачать генерировать ответ, пока не будет по- лучепо сообщение-запрос от клиента. Точно так же, извлечение данных с диска может задержать передачу сообщения-ответа. Ожидая завершения операции, сервер должен иметь возможность переключиться на другой запрос. Это требует тщателыюго анализа операций, которые могут заблокировать процесс на сервере. Web-сервер активизирует системные вызовы операционной системы для выполнения низкоуровневых задач, относящихся к сетевым соединениям и операциям с дисковой памягыо. Чтобы избежать ожидания завершения выполнения этих задач, Web-сервер с управлением по событиям обычно осуществляет неблокирующие системные вызовы, которые позволяют вызвавшему процессу продолжать выполнение, ожидая ответа от операционной системы. При завершении выполнения системной операции возбуждается событие, которое должно быть обработано серверным процессом.

В любой заданный момент времени сервер может иметь одно или более событий, связанных с различными Web-запросами, обработка которых не закончена. Обработка событий может инициировать дополнительные системные вызовы, которые, в свою очередь, приводят к возбуждению новых событий. Например, предположим, что клиент заирашивает статический ресурс, хранящийся на диске сервера. После получения клиентского запроса и преобразования URL в путь к файлу в файловой системе сервер инициирует событие для извлечения соответствующего файла с диска. В процессе ожидания поступления данных с диска сервер может обработать другой запрос. Обработка всех запросов в одном процессе дает возможность серверу последовательно упорядочить действия, которые модифицируют одпи и те же данные. Это особенно важно применительно к Web, поскольку HTTP-запросы могут инициировать создание или модификацию Web-pecypcoB. Предположим, что два пользователя пытаются одновременно изменить один и тот же ресурс. Сервер с управлением по событиям может легко сделать так, чтобы одна операция записи завершилась до того, как будет пачата следующая. Кроме того, обработка запросов в рамках одиого процесса облегчает совместное использование данных разными запросами. Предположим, например, что два пользователя выдают один и гот же запрос на поиск. Сервер может кэшировать результат выполнения первого запроса и вериуть тот же самый ответ для второго запроса.

Выполнение запросов в одном -процессе с управлением по событиям имеет смысл, если каждое событие вносит небольшую задержку, величина которой не может превышать некоторого значения. Например, синтаксический Анализ НТТР-за- проса представляет собой относительно простую задачу. Однако другие операции, такие как ожидание получения HTTP-запроса, могут обусловить длительную задержку. К счастью, операционная система берег на себя эти функции, давая возможность серверному процессу обрабатывать в это время другие запросы. Тем не менее, некоторые HTTP-запросы впосят более существенную задержку, чем другие. Написание серверного программного обеспечения, которое позволяет явно переключаться между запросами, существенно осложняет разработку программных средств для сохранения промежуточных результатов каждого запроса. Например, динамически генерируемые Web-ответы Обычно требуют от сервера вынолпепия сцепария. Сервер может не зпать заранее, как долго будет выполняться сценарий. Если допустить неопределенно долгое выполнение сценария, то это может привести к большим задержкам для других запросов. Вместо этого следует выполнять сценарий в отдельном процессе, чтобы дать возможность серверу обработать другие запросы.

Сервер с управлениям по событиям существенно зависит от эффективной поддержки операционной системой неблокирующих системных вызовов. Поддержка неблокирующих системных вызовов отличается для различных операционных систем. На практике неблокирующие операции, которые взаимодействуют с сетевым интерфейсом, обладают хорошим быстродействием. Взаимодействие с дисковой подсистемой вызывает больше проблем. Например, неблокирующий системный вызов для чтения файла с диска может, тем не менее, заблокировать вызвавший процесс в ходе выполнения операции с диском. Это может снизить производительность Web-cepBe- pa и увеличить время ожидания ответа. Подобные ограничения операционной системы вместе с проблемами при разработке серверного программного обеспечения являются доводами против архитектуры с управлением по событиям. Как результат, большинство высокопроизводительных Web-серверов не используют подобную архитектуру. Несмотря на это, некоторые экспериментальные Web-серверы реализуют модель с управлением по событиям, а элементы, присущие подходу с управлением по событиям, находят применение в других архитектурах.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100