Оптимизация взаимодействия веб-клиента и сервера - Введение
Всемирная паутина (www) начиналась с полностью статичных веб-ресурсов, так что пользователи могли лишь просматривать предложенные веб-странички и скачивать файлы. Со временем появлялись все более развитые средства взаимодействия с пользователями, начали использовать кукисы (cookie) для идентификации пользователей, предложили формы обратной связи и форумы. Сегодня многие веб-сайты обзавелись базами данных и активно применяют ajax-технологию для удобства посетителей, и для нас стал привычен термин "веб-приложения". Происходящее сравнимо с революционными изменениями, порожденными открытием книгопечатания, и даже более того - ведь теперь не только информация стала как никогда раньше доступной и глобальной, но и каждый ее потребитель легко и быстро может связаться с автором, включаясь таким образом в процесс создания новой информации. Все это здорово, но техническая часть взаимодействия между веб-приложениями и их пользователями производит впечатление чрезвычайно сложного процесса, требующего сложнейших программных решений. Но так ли это на самом деле? В предлагаемой вашему вниманию статье автор постарался показать, насколько просты принципы, лежащие в основе современного веба, и как легко можно стать полноправным участником построения всемирной сети. Печатная машинка делает процесс печати доступным каждому из нас, но большая типография производит впечатление сложного и непостижимого для неспециалиста технологического процесса. Да, технологически типография сложна, но суть ее - быть высокопроизводительной печатной машинкой. Вероятно, уже спустя 10 лет мы вовсе забудем о существовании типографий, поскольку дальнейшее развитие технологий сделает их ненужной ветвью эволюции информационного общества. Ровно так же и в области информационных технологий есть свои рабочие инструменты и есть огромные монстры, причем последние являются лишь данью нашему времени. Для сравнения мы будем упоминать и монстров, названия которых знакомы многим нашим читателям, но главное, постараемся показать основные идеи и те основные инструменты, которые позволяют их воплотить в жизнь. Автор уверен, что статья окажется полезной как начинающим разработчикам, так и профессионалам, поскольку обсуждения многих затрагиваемых здесь вопросов показывают, как мало разработчиков задумываются о том, что они делают, будучи вместо этого всецело поглощены мыслью о том, как это делать.
С чего же начинается построение веб-ресурса? Для создания и отправки созданного цифрового контента клиентам служит программное обеспечение, называемое веб-сервером. Существуют разнообразные веб-серверы, от маленьких и простых до огромных и сложных, к тому же требующих дополнительных внешних программ для своей работы. Выбор веб-сервера задача непростая, и во многих проектах используются разное программное обеспечение для передачи статических, заранее подготовленных файлов, так называемой "статики" и динамически создаваемых данных, или кратко "динамики". Также в некоторых случаях выделяются задачи потоковой трансляции мультимедиа-содержимого и некоторые другие, которые мы рассматривать не будем, поскольку такие вопросы являются узкоспециализированными и выходят за рамки текущей статьи (большинство сайтов работают с таким содержимым ровно также, как с обычной статикой). Ниже будет представлен обзор некоторых популярных решений и предложен миниатюрный и не требующий настройки веб-сервер для раздачи статики, а также технология управления генерацией динамического содержимого. Как будет показано, разница в быстродействии между самыми сложными и самыми простыми решениями часто невелика, в то время как разница между затрачиваемым на их изучение и настройку временем огромна.
Выбор веб-сервера определяется решаемой задачей, или, скорее, должен определяться. На практике большинство разработчиков во всех проектах более или менее успешно работают с тем веб-сервером, к которому привыкли, что может создавать различные проблемы. Такие решения отличает избыточная сложность реализации и настройки, а также производные от этого проблемы с безопасностью, масштабированием и другие. Поскольку по системам подобного рода пишется больше всего обзоров и технических статей, создается ложное впечатление, что это именно то, к чему надо стремиться.
Во многих случаях оптимально и достаточно ограничиться одним из миниатюрных веб-серверов для отдачи статики, технологии CGI для динамики и балансировщика нагрузки, если проект достаточно большой и один веб-сервер не справляется. Далее везде предполагается, что на сервере работает именно операционная система Linux (с ядром 2.6.26 и выше) или другая UNIX-система.
Хотя веб-сервер является необходимым компонентом, зачастую его недостаточно и для оптимизации производительности и времени отклика веб-ресурса применяются еще и так называемые реверс-прокси серверы (обратные прокси), которые представляют собой "единое окно" для доступа всех пользователей к одному или более "спрятанных" веб-серверов. Для рассматриваемой архитектуры существует калька с английского названия фронтэнд (front-end) для прокси-сервера (в общем случае - компонента, непосредственно взаимодействующего с пользователями), и бэкенд (back-end) для компонентов, непосредственно выполняющих обработку запросов, но невидимых для пользователей. Реверс-прокси лишь передают запросы на обработку далее, при этом они могут модифицировать как запрос, так и полученный результат (удалить небезопасные данные или, наоборот, добавить дополнительные данные). Преимущество от работы обратного прокси достигается за счет "умного" управления очередью пользовательских запросов и распределения этих запросов по бэкендам (в том числе, осуществляется балансировка запросов по нескольким одинаковым бэкендам, передача определенных типов запросов нужным бэкендам и обеспечение минимального времени ожидания запросов пользователей в очереди, блокирование сетевых атак многих типов). Для небольших проектов реверс-прокси часто работает на том же физическом сервере, что и бэкенды, и даже в этом случае выгоды от такого дополнительного компонента весьма ощутимы. Из-за того, что пользователь не видит разницы между обращением непосредственно к веб-серверу или к реверс-прокси, во всех случаях установленное на сервере программное обеспечение зачастую называют одинаково - веб-сервер.
На пути между веб-ресурсом и компьютером клиента (которым может быть как настольный компьютер, так и смартфон или другое мобильное устройство) обычно располагаются кэширующие прокси интернет-провайдеров, корпоративных сетей и другие. Задачей кэширующих прокси является сохранение неизменяемых или редко изменяемых файлов на определенный интервал времени. При поступлении HTTP-запроса, кэширующий прокси или возвращает ранее сохраненный результат из кэша, или передает запрос далее (к следующему прокси или непосредственно веб-сервису), а результат выполнения запроса возвращает, притом сохраняет его в кэше, если это разрешается заголовками HTTP-запроса. Дополнительно возможно использование собственного кэширующего прокси. Кроме стандартных преимуществ, свой прокси дает возможность применить нестандартные настройки для более агрессивного кэширования и снижения нагрузки на обработку запросов (но не стоит злоупотреблять нестндартным поведением кэширующего прокси, лучше правильно настроить заголовки кэширования непосредственно в бэкендах).
Грамотный выбор веб-сервера или нескольких серверов, установка реверс-прокси и учет существования кэширующих прокси на пути траффика от веб-ресурса способны кардинально повысить качество работы проекта и снизить нагрузку на серверное оборудование. Минимально необходимым компонентом для своего сайта является только веб-сервер; впрочем, многие хостеры предоставляют веб-сервер и реверс-прокси даже для недорогих тарифных планов.
В качестве критериев оценки мы будем показывать скорость обработки запросов, измеряемую в транзакциях в секунду (TPS - transaction per second). Измерения будут проводиться на моем нетбуке Intel(R) Atom(TM) CPU N450 1.66GHz. Почему именно нетбук? Ну, во-первых, именно на нем я пишу статью и мне это удобно :-) Основная же причина - показанные значения будут достаточно близки к тому, что мы получаем на бюджетных хостингах. Если же вы примените описанные далее методики на хорошем железе, то будете приятно удивлены. Я мог бы провести замеры на топовом "железе" и получить высокие цифры для украшения статьи, но это бы не привело ни к чему иному, как к разочарованию большинства читателей при практическом использовании представленного материала.
Во многих примерах показаны однопоточные обработчики, и вот почему. Специализированный балансировщик запросов выполнит задачу распараллеливания запросов почти всегда лучше, нежели встроенный в веб-сервер модуль балансировки, что, вдобавок, чрезвычайно упрощает логику самого обработчика запроса, делая его однопоточным. Занять все доступные ядра просто, запустив несколько однопоточных обработчиков на разных портах и настроив балансировку входящих запросов по этим портам в реверс-прокси, а масштабирование по числу процессоров/ядер становится наилучшим - линейным.
С чего же начинается построение веб-ресурса? Для создания и отправки созданного цифрового контента клиентам служит программное обеспечение, называемое веб-сервером. Существуют разнообразные веб-серверы, от маленьких и простых до огромных и сложных, к тому же требующих дополнительных внешних программ для своей работы. Выбор веб-сервера задача непростая, и во многих проектах используются разное программное обеспечение для передачи статических, заранее подготовленных файлов, так называемой "статики" и динамически создаваемых данных, или кратко "динамики". Также в некоторых случаях выделяются задачи потоковой трансляции мультимедиа-содержимого и некоторые другие, которые мы рассматривать не будем, поскольку такие вопросы являются узкоспециализированными и выходят за рамки текущей статьи (большинство сайтов работают с таким содержимым ровно также, как с обычной статикой). Ниже будет представлен обзор некоторых популярных решений и предложен миниатюрный и не требующий настройки веб-сервер для раздачи статики, а также технология управления генерацией динамического содержимого. Как будет показано, разница в быстродействии между самыми сложными и самыми простыми решениями часто невелика, в то время как разница между затрачиваемым на их изучение и настройку временем огромна.
Выбор веб-сервера определяется решаемой задачей, или, скорее, должен определяться. На практике большинство разработчиков во всех проектах более или менее успешно работают с тем веб-сервером, к которому привыкли, что может создавать различные проблемы. Такие решения отличает избыточная сложность реализации и настройки, а также производные от этого проблемы с безопасностью, масштабированием и другие. Поскольку по системам подобного рода пишется больше всего обзоров и технических статей, создается ложное впечатление, что это именно то, к чему надо стремиться.
Во многих случаях оптимально и достаточно ограничиться одним из миниатюрных веб-серверов для отдачи статики, технологии CGI для динамики и балансировщика нагрузки, если проект достаточно большой и один веб-сервер не справляется. Далее везде предполагается, что на сервере работает именно операционная система Linux (с ядром 2.6.26 и выше) или другая UNIX-система.
Хотя веб-сервер является необходимым компонентом, зачастую его недостаточно и для оптимизации производительности и времени отклика веб-ресурса применяются еще и так называемые реверс-прокси серверы (обратные прокси), которые представляют собой "единое окно" для доступа всех пользователей к одному или более "спрятанных" веб-серверов. Для рассматриваемой архитектуры существует калька с английского названия фронтэнд (front-end) для прокси-сервера (в общем случае - компонента, непосредственно взаимодействующего с пользователями), и бэкенд (back-end) для компонентов, непосредственно выполняющих обработку запросов, но невидимых для пользователей. Реверс-прокси лишь передают запросы на обработку далее, при этом они могут модифицировать как запрос, так и полученный результат (удалить небезопасные данные или, наоборот, добавить дополнительные данные). Преимущество от работы обратного прокси достигается за счет "умного" управления очередью пользовательских запросов и распределения этих запросов по бэкендам (в том числе, осуществляется балансировка запросов по нескольким одинаковым бэкендам, передача определенных типов запросов нужным бэкендам и обеспечение минимального времени ожидания запросов пользователей в очереди, блокирование сетевых атак многих типов). Для небольших проектов реверс-прокси часто работает на том же физическом сервере, что и бэкенды, и даже в этом случае выгоды от такого дополнительного компонента весьма ощутимы. Из-за того, что пользователь не видит разницы между обращением непосредственно к веб-серверу или к реверс-прокси, во всех случаях установленное на сервере программное обеспечение зачастую называют одинаково - веб-сервер.
На пути между веб-ресурсом и компьютером клиента (которым может быть как настольный компьютер, так и смартфон или другое мобильное устройство) обычно располагаются кэширующие прокси интернет-провайдеров, корпоративных сетей и другие. Задачей кэширующих прокси является сохранение неизменяемых или редко изменяемых файлов на определенный интервал времени. При поступлении HTTP-запроса, кэширующий прокси или возвращает ранее сохраненный результат из кэша, или передает запрос далее (к следующему прокси или непосредственно веб-сервису), а результат выполнения запроса возвращает, притом сохраняет его в кэше, если это разрешается заголовками HTTP-запроса. Дополнительно возможно использование собственного кэширующего прокси. Кроме стандартных преимуществ, свой прокси дает возможность применить нестандартные настройки для более агрессивного кэширования и снижения нагрузки на обработку запросов (но не стоит злоупотреблять нестндартным поведением кэширующего прокси, лучше правильно настроить заголовки кэширования непосредственно в бэкендах).
Грамотный выбор веб-сервера или нескольких серверов, установка реверс-прокси и учет существования кэширующих прокси на пути траффика от веб-ресурса способны кардинально повысить качество работы проекта и снизить нагрузку на серверное оборудование. Минимально необходимым компонентом для своего сайта является только веб-сервер; впрочем, многие хостеры предоставляют веб-сервер и реверс-прокси даже для недорогих тарифных планов.
В качестве критериев оценки мы будем показывать скорость обработки запросов, измеряемую в транзакциях в секунду (TPS - transaction per second). Измерения будут проводиться на моем нетбуке Intel(R) Atom(TM) CPU N450 1.66GHz. Почему именно нетбук? Ну, во-первых, именно на нем я пишу статью и мне это удобно :-) Основная же причина - показанные значения будут достаточно близки к тому, что мы получаем на бюджетных хостингах. Если же вы примените описанные далее методики на хорошем железе, то будете приятно удивлены. Я мог бы провести замеры на топовом "железе" и получить высокие цифры для украшения статьи, но это бы не привело ни к чему иному, как к разочарованию большинства читателей при практическом использовании представленного материала.
Во многих примерах показаны однопоточные обработчики, и вот почему. Специализированный балансировщик запросов выполнит задачу распараллеливания запросов почти всегда лучше, нежели встроенный в веб-сервер модуль балансировки, что, вдобавок, чрезвычайно упрощает логику самого обработчика запроса, делая его однопоточным. Занять все доступные ядра просто, запустив несколько однопоточных обработчиков на разных портах и настроив балансировку входящих запросов по этим портам в реверс-прокси, а масштабирование по числу процессоров/ядер становится наилучшим - линейным.
Comments