Тезисы

Тезисы:

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

• фронтенд-системы, для быстрой отдачи статического и кэшированного контента (nginx, lighttpd, etc.)
• бэкэнд-системы, для генерации динамического контента (Apache, spawn-fcgi, на которых крутится интерпретатор того или иного языка, например: PHP, Perl или виртуальная машины Java).
• СУБД, для операций с данными, (MySQL, Postgres).

В каждом из этих слоев есть свои подсистемы кеширования: встроенные механизмы кэширования результатов выборок для СУБД, Опкод кэшеры и кэшеры промежуточных данных для уровня бэкенда, различные mod_proxy и mod_cache для фронтенд серверов.

Давайте представим на минуту, что у нас нет всех этих замечательных "ускорителей интернета". Тогда любой запрос полученный сервером от пользователя пройдет все три ступени от фронтенда к БД: сначала фронтенд получит запрос на генерацию страницы, передаст его бэкенду, который загрузит с диска и (во многих случаях ) начнет интерпретировать код через соответствующий интерпретатор, в свою очередь, пойдет за данными в БД, которая будет выбирать из файлов на диске.

Я люблю, когда скорость реакции веб-сервиса на мое действие не превышает 100 мс, а при такой дорожке запроса и высокой нагрузке такая цифра просто недостижима. Возвращая на место кеширование, мы можем постепенно снижать нагрузку на слои приложения снизу вверх. Если кешировать данные в кешер бэкенда, то можно сократить количество запросов к БД. Если кешировать на фронтенде в память страницы, то можно разгрузить бэкенд.

Идея в том чтобы оставаться как можно выше в слоях приложения как это только возможно. Помимо скорости отдачи это дает возможность скейлить горизонтально только фронтенды, а под ними держать бэкенды под различные задачи. Ведь в большинстве случаев операции по изменению/добавлению информации происходят гораздо реже чем операции чтения.

И тут мы подходим к кульминации. Вспомнив то, что lighttpd и nginx лучше всего отдают статику, то можно с помощью них эту самую статику и отдавать. Около шести лет назад, обозревая интернет (когда UGC был еще не в моде) я задавался вопросом, зачем иметь столько динамических страниц, которые вполне себе могут быть статическими HTML файлами. Не найдя внутри себя никаких концептуальных противоречий этой идее, я начал искать в ней технические изъяны. Таких оказалось ровно четыре:

• Часто 90% страницы может быть закешировано навека (статья в блоге), а комментарии, например, могут обновляться с определенной частотой.
• На странице может быть блок персональной информации пользователя, которая для каждого посетителя уникальна.
• При изменениях какой-либо информации необходимо знать какие еще статические страницы ее отображают чтобы их обновить.
• Может появиться огромное количество файлов, которые будут давать существенную нагрузку на файловую систему.

Первая проблема долго не давала мне покоя, пока я не подумал об SSI, старой доброй технологии сборки страниц на сервере. Таким образом можно собрать страницу из кусочков, которые можно обновлять независимо друг от друга.

Вторая проблема решается персональным кешированием, идентификатором является куки сессии, получаемое от пользователя. Третья проблема на данный момент широко известна в системах кеширования на бэкенде, существуют варианты связывания элементов кеша через теги. Я думаю было бы правильно просто убивать все файлы, которые связаны с изменяемой сущностью, чтобы он потом сгенерились по требованию.

Четвертая проблема носит неявный характер, я проектировал систему в которой 6 миллионов статических файлов, которые расположены в директориях по части md5 от их имени: /05/fe/index.html. Под большой нагрузкой (60 тыс. посетителей в сутки) такая структура не вызывала никаких проблем.

Все вместе.

Итак, я хочу взять быстрый и легкий фронтенд сервер lighttpd, отправлять ему запросы, в случае удовлетворения которых, он помимо отдачи этих страниц генерил бы статические html файлы и раскладывал-бы их так, чтобы при следующем таком запросе отдавались бы они. Первый вариант был сделать это через ssi+errorhandler-404. Генератор вешается на 404 обработчик, и если URI запроса удовлетворяет условию, то генерится файл, если нет, то браузер получает 404. Сразу же выяснилось, что ssi в лайти не поддерживает саб-реквесты (то есть include-virtual не вызывает еще одну http-транзакцию, а просто пытается найти и отдать содержимое файла) и проблема персонального кеша тоже не решается, так как в ssi нет средств для получения кук пользователя.

В общем ничего не оставалось, как писать модуль для лайти. В результате месяца упорной работы появились mod_cache_indexfile и mod_ext_ssi. Первый перехватывает все ошибочные 404 запросы и вызывает генератор для создания и отдачи статических файлов. Второй расширяет возможности ssi для подключения внутренних и персональных блоков.

Список директив для модулей:

mod_cache_indexfile

• gen-cache.bin-path = "/usr/bin/php-cgi" - fastcgi интерпретатор, который будет запускать скрипт генератора.
• gen-cache.generator-path = "/mymedia/projects/test-cache/generator.php" - путь к скрипту генератора.
• cache-index-file.name = "index.html" - имя файла, который будет создаваться как индекс директории. При запросе /myposts/brand_new_lighttpd_mod/ будет создана такая структура папок и файлов: project/www/myposts/brand_new_lighttpd_mod/index.html

mod_ext_ssi

• ssi-ext.extension = ( ".html" ) - расширение, файлы с которым будет обрабатывать модуль.
• cache-file.cookie-name = "personalCache" - имя куки, из которого будет вычитываться уникальный идентификатор пользователя, для создания персонального кеша.

Модуль mod_ext_ssi делает доступными следующие SSI инструкции:

• - для подключения блоков с поддержкой генерации статики внутри страниц.
• - для подключения блоков персональной информации с поддержкой генерации статики внутри страниц.

На данный момент модули полностью готовы и я планирую их внедрение в своем следующем проекте. (Частично концепция уже используется в моем предыдущем проекте.)

Вообще кешировать в статику при стремительно наступающих SSD (стирает границы между ОЗУ и ПЗУ) и Cloud Computing может стать очень перспективно. Это также дает отличные возможности для CMS систем, в которых можно использовать такой механизм для разделения статических и динамических страниц. И хостеры таких CMS смогут вместить на один условный сервер много больше проектов, в случае если большая часть страниц будут просто статическими файлами.