62
разбиение на страницы, как на форумах), если был применен метод POST. В
случае использования Nginx Plus и кэшируемых SSI блоков с сообщениями,
как было описано в разделе 1 главы 3, это возможно и реализуется
относительно просто.
Рассмотрим на примере тестового приложения. Nginx Plus является
коммерческой программой, но имеется некоммерческий модуль ngx
_cache_purge, который предлагает аналогичный функционал[26]. Для его
использования с ним необходимо скомпилировать nginx. Для простоты и
наглядности образ, на базе которого строится контейнер nginx, был заменен с
nginx:latest на emcniece/nginx-cache-purge:1.13-debian, в котором запускается
nginx с нужным нам модулем.
Структура стека приложения, по сравнению с предыдущем разделом,
не изменилась. Файл docker-compose.yml, используемый в этом разделе,
приведен в приложении 5. Для примера не создается отдельный стек, а
модифицируется уже имеющийся, так как значительных изменений не
вносится ни во что, кроме конфигурационного файла nginx.conf, текст
которого приведен в приложении 10.
Незначительный изменения потребовалось сделать в сценарии
render.php. Между 11 и 12 строками появилась строка
file_get_contents("http://nginx/purge/render.php?arg=" . $_GET['arg'] .
"&num=" . $_GET['num']);
Она означает, что после выполнения запроса POST необходимо
выполнить GET запрос к NGINX, который направит его в определенную
локацию purge и очистит кэш, определив страницу по части uri после purge.
Для хранения кэша используется каталог без уровней, в который попадают
md5 суммы от fastcgi_cache_key $uri$is_args$args.
Как можно заметить, локация @nocache убрана, теперь есть всего 4
локации:
1. Корневая локация, в которой объявлены только индексный файл и
путь, где его искать. Это нужно для того, чтобы пользователь мог
63
попасть на сайт только по имени домена. Это один из способов,
также можно применять rewrite к пустым uri. Как только находится
индексный файл, в работу вступает локация для обработки файлов
html;
2. Purge, удаляющая страницу из кэша. Знак ^~ означает, что локацию
нужно рассматривать только как подстроку и не прибегать к
сравнению с регулярным выражением. Такое сравнение делается
раньше и предотвращает попадания запроса с uri, содержащим .php
в локацию к fastcgi серверу. Директивы allow и deny предписывают
серверу принимать запросы к этой локации только из внутренней
сети docker и отклонять все остальные, чтобы кто угодно не смого
портить кэш;
3. Локация для статических файлов, где происходит поиск всего, что
можно отдать – иконки, изображения и другие типы файлов. К ним
же относытся статические страницы html. Директива ssi on
предписывает nginx обрабатывать блоки ssi в таких страницах;
4. Локация для обработки запросов к скриптам php, направляющая эти
запросы на fastcgi сервер и, затем, кэширующая их. В директиве
fast_cgi_cache_key переназначается ключ, по которому будут
кэшироваться страницы. По этому значению будет однозначно
идентифицироваться страница при ее получении из кэша, или
удалении. Так как на сервере имеется всего один сайт, который
работает по одному протоколу и всего одна область кэша, этого
ключа вполне достаточно.
Параметры кэша изменены – теперь он валиден в течение часа. Однако,
запись в базу данных при выполнении POST запроса удаляет страницу из
кэша.
Это то, что требуется для оптимальной работы кэширования с
основным приложением – после сообщения в задачу можно сгенерировать
несколько запросов к различным страницам, которые должны обновиться, и
64
очистить их кэш. При этом при наличии других блоков ssi на странице, их
можно не очищать, если они не должны измениться. Страница кэшируется
частями, которыми можно эффективно управлять.
3.3.2. Анализ прироста производительности
В этом разделе будет применена методика оценки производительности,
аналогичная методикам из двух предыдущих разделов. На основе файла
журнала доступа сформируем отчет о среднем времени работы:
Рисунок 21. Журнал доступа приложения с очисткой кэша.
Обратите внимание на GET запросы с адреса 172.28.0.4. Это запросы на
очистку кэшированной страницы с сообщениями. В следующий раз страница
загружается с fastcgi сервера заново. Последние несколько строк – это
дополнительные визиты на страницы со списком и сообщениями. По
времени видно, что они берутся из кэша.
Такая модель работы приложения наиболее оптимальная, так как
совмещает в себе все сильные стороны предыдущих примеров:
1. Быстро работает со статическими файлами;
2. Применяется кэширование там, где это необходимо
Кэш чистится специальным запросом из кода приложения, поэтому
такой подход требует модификации приложения.
Следует также отметить очень важную сторону работы приложения по
такой модели – высокую отказоустойчивость. Так как страницы очищаются
принудительно, их можно кэшировать надолго и они будут оставаться
валидными, пока кто-нибудь не запишет новое сообщение в базу.
65
Если, например, пропала связь с серверами бек-энда, nginx продолжит
отдавать пользователям кэшированное содержимое, у них только не
получится ни чего добавлять. Это несомненное преимущество перед всеми
рассмотренными ранее моделями, так как в них динамическое содержимое
хранится в кэше крайне недолго из-за отсутствия возможности
принудительной очистки.
Вывод, который следует сделать в завершении этого раздела –
необходимо продумывать на этапе проектирования приложения, как будет
работать кэш и, при наличии возможностей, обязательно предусмотреть
способы его принудительной очистки. Это позволит сделать кэширование
более гибким и эффективным.
3.3.3. Анализ устойчивости к сбоям
Применим ту же методику, которая использовалась в разделах 3.1.3 и
3.2.3. После обхода всех страниц в кэше создалось 3 файла – блоки списка и
двух задач:
root@c21d3e6fcad5:/# ls -la /var/nginx/cache/
total 40
drwx------ 2 nginx root 4096 Oct 6 19:32 .
drwxr-xr-x 3 root root 4096 Oct 6 19:28 ..
-rw------- 1 nginx nginx 9847 Oct 6 19:32 7c128f067dc1b52bf3f72420f8769317
-rw------- 1 nginx nginx 1070 Oct 6 19:32 8e02129edeca5ea2d1c31ba68a766796
-rw------- 1 nginx nginx 12965 Oct 6 19:32 fe01017f309b0efef7d44d5adc04b5ba
Теперь выполним остановку сервера fpm:
sudo docker-compose stop fpm
Переход на страницу списка удался, как и ее обновление кнопкой F5.
Переход в задачу 1 также завершился успешно – кэшированное содержимое
блока мгновеннол отобразилось на странице. Попытка отправить запрос
POST при добавлении сообщения привела к ошибке 502 – Bad gateway.
66
После этого осталась возможность вернуться на предыдущую страницу
с сообщениями, из нее перейти к списку, зайти в другую задачу. По внешним
признакам приложение работает, но попытка отправить сообщение
завершается ошибкой на сервере. Можно добавить в локацию \.php$
директиву error_page 502 = /index.html$is_args$args;, тогда вместо страницы с
ошибкой пользователь просто перенаправляется, в данном случае, на ту же
страницу, с которой была выполнена попытка отправить POST запрос. Это
самый простой вариант внешне скрыть неработоспособность, однако, налицо
неадекватное поведение приложения – оно работает но сообщения не
пишутся.
Правильным подходом в этом случае будет разделить страницу с
сообщениями на два блока:
1. Блок с самими сообщениями
2. Блок с формой для отправки
Для этого понадобится небольшая модификация скрипта render.php.
Далее, настроить nginx так, чтобы блок с формой отправки сообщений
не кэшировался - в локации \.php$ добавить директиву fastcgi_no_cache
$arg_nocache;
Также необходимо будет внести изменения в шаблон index.html:
Необходимо будет добавить директиву ssi, включающую блок с
формой для отправки сообщений после директивы, добавляющей тело
сообщений:
<!--#include virtual="/render.php?arg=messages&num=$arg_num" -->
<!--#include virtual="/render.php?arg=form&num=$arg_num&nocache=1"
stub="NoForm"-->
Параметр stub предписывает nginx включать блок NoForm вместо
формы, если сервер fpm окажется недоступен. Блок следует описать до
директивы включения:
<!--#block name="NoForm" -->
<p>Отправка сообщений временно невозможна</p>
67
<!--#endblock -->
Аргументы num и nocache в данном случае понадобятся для корректной
работы скрипта и конфигурации nginx.
Далее необходимо сбросить кэш на nginx, применить новый файл
конфигурации и обойти все страницы приложения. После этого в кэше
окажутся 3 файла:
root@c21d3e6fcad5:/# ls -la /var/nginx/cache/
total 40
drwx------ 2 nginx root 4096 Oct 6 20:39 .
drwxr-xr-x 3 root root 4096 Oct 6 19:28 ..
-rw------- 1 nginx nginx 9745 Oct 6 20:39 7c128f067dc1b52bf3f72420f8769317
-rw------- 1 nginx nginx 1070 Oct 6 20:36 8e02129edeca5ea2d1c31ba68a766796
-rw------- 1 nginx nginx 12709 Oct 6 20:39 fe01017f309b0efef7d44d5adc04b5ba
Это блок списка и два блока с сообщениями. Если проверить
содержимое этих файлов, формы ввода сообщений в них не окажется.
Далее выключается контейнер fpm и при попытке перехода на
страницу с сообщениями, она примет следующий вид:
Рисунок 22. Отсутствие формы при неработоспособности бек-энда.
Вместо формы получено сообщение «Отправка сообщений временно
невозможна». При этом без бекэнда приложение сможет работать столько,
сколько кэшированные страницы будут оставаться в кэше (параметр inactive
директивы fastcgi_cache_path, в данном случае – 1 час). В этом разделе было
продемонстрировано приложение, устойчиво к сбоям на бек-энд серверах,
68
способное сохранять ограниченную функциональность даже в случае выхода
из строя всех бек-энд серверов.
Возможность хранить в кэше динамическое содержимое появляется
только при возможности его очистки. Эта возможность Nginx Plus и модуля
Nginx Cache Purge явно заслуживает внимания и при модификации основного
приложения РМС, рассмотренного в работе, несомненно, будет
задействована.
69
ЗАКЛЮЧЕНИЕ
По результатам проделанной работы можно сделать общий вывод –
nginx представляет собой очень мощное средство, позволяющее значительно
повысить производительность и устойчивость как веб-приложений, так
различных служб, использующих для взаимодействия с внешним миром
протокол tcp. Это достигается благодаря модульной архитектуре,
позволяющей подключать к системе различные модули, по мере
необходимости в дополнительных функциях.
Цели, которые ставились при написании данной работы, достигнуты:
1. Был выполнен обзор современной отрасли веб технологий и
рассмотрены некоторые из них. Отдельно отмечена важность
быстродействия веб-приложений, коррелирующая с количеством
пользователей и, в конечном счете, с успехом или провалом
проектов.
2. Особое внимание было уделено технологии контейнеризации
приложений с помощью Docker и оркестрации контейнеров с
помощью Docker compose. Эти технологии применялись
впоследствии на протяжении всей работы при выполнении
практической части.
3. Выполнен обзор архитектуры и основных возможностей nginx и
потенциала, который открывается при его использовании в качестве
кэширующего прокси-сервера.
4. Рассмотрено приложение РМС, являющееся объектом исследования
в работе. В ходе анализа были определены категории страниц,
которые невозможно кэшировать по ряду причин, не применяя
принудительную очистку кэша. Также были определены категории
страниц и файлов, которые необходимо кэшировать.
5. Выполнена подготовка приложения РМС, уcтановка кэширующего
прокси-сервера и его настройка. Был использован Nginx 1.15, образ
70
которого на момент выполнения работы был доступен в ветке
nginx:latest на hub.docker.io
6. Выполнен анализ результатов внедрения – собран журнал доступа и
обработан с помощью скрипта, написанного на языке awk. После
обработки журнала скриптом была получена статистика посещений
страниц приложения, проанализировано время и выигрыш от
кэширования. Сделан вывод, что если даже не кэшировать все
страницы, выигрыш в производительности ощутим и даны
рекомендации как улучшить результат.
7. Подготовлено тестовое приложение, имитирующее работу
основного – страница со списком задач и две задачи, в которых
можно оставлять сообщения. Проанализирована
производительность работы тестового приложения при архитектуре
стека, схожей с архитектурой стека приложения РМС. Оценена
устойчивость к сбоям.
8. На примере тестового приложения продемонстрировано
преимущество использования nginx в качестве основного веб-
сервера после отказа от Apache. Продемонстрировано преимущество
использования в данном случае технологии SSI. Позволяющей
загружать страницу по блокам. Также была проанализирована
производительность приложения, работающего на основе таких
технологий и его устойчивость к сбоям. Отдельно
продемонстрирована устойчивость к сбоям на сервере СУБД при
использовании нескольких серверов и репликации между ними.
9. На примере тестового приложения показаны преимущества, которые
могут быть получены при использовании принудительной очистки
кэшированных страниц после изменения данных. После внесения
всех необходимых изменений в тестовое приложение и анализа
производительности, был получен хороший результат при
тестировании устойчивости к сбоям на серверах бек-энда. В течение
71
времени хранения страниц в кэше приложение оставалось
доступным для чтения, при этом о невозможности в данный момент
изменять данные сообщалось пользователям отдельным блоком.
Считаю, что цели, которые ставились при написании данной работы,
достигнуты в полном объеме.