Эксперты проанализировали влияние используемых некоторыми сайтами инструментов кэширования контента на скорость загрузки веб-страниц. Полученные данные помогут владельцам сайтов и разработчикам выделить для себя наиболее подходящую конфигурацию сервера. Обычным пользователям сети будет интересно поближе познакомиться со схемой взаимодействия сайта с посетителем и узнать, по какому принципу сайт кэширует ту или иную информацию.
2. Методология тестирования кэширования
Введение
Постарайтесь вспомнить, что у вас было на обед вчера. Это должно занять у вас 3-5 секунд. А теперь вспомните еще раз. Во второй раз это заняло меньше секунды, не так ли?
Вы вспомнили гораздо быстрее во второй раз, потому что вам не пришлось «запрашивать» эту информацию из «хранилища» вашего мозга. Информация была кэширована. Тот же принцип применяется в системе кеширования веб-сайта, правда, на базовом уровне.
Существует несколько инструментов для кэширования содержимого веб-сайтов, включая популярные плагины и сети доставки контента (CDN). Мы решили провести серию экспериментов (включая моделирование DoS-атак), чтобы оценить влияние инструментов кеширования на производительность сайта.
Методология тестирования кэширования
Для проведения тестов был развернут небольшой сервер WordPress, расположенный в Лос-Анджелесе (США). Был установлен только один плагин для создания фиктивного контента и наполненности, чтобы соответствовать поведению реального сайта.
Рисунок 1. Тестовая инсталляция WordPress
Примечание: Все тесты были воспроизведены три раза, были отображены лучшие результаты.
Для измерения производительности использовался сервер во Франции и программное обеспечение под названием (версия 3.0.8). Задействовалась следующая команда:
Рисунок 2. Команда, использовавшаяся для измерения производительности
timeout -sHUP 1msiege -c1 test-domain.com
Для интересующихся приведем несколько примеров того, как эта команда может использоваться:
Рисунок 3. Запустить команду в течение минуты, а затем завершить
timeout -sHUP 1m
Рисунок 4. Запустить пользователя в домене test-domain.com
siege -c1 test-domain.com
Тест №1. Нет кэширования — одно подключение
Первым делом нам нужно заложить какую-то основу нашим результатам, поэтому мы проведем тест скорости без инструментов кэширования на сайте. Используем только один запрос на сайт, как будто соединение инициировал один пользователь.
Рисунок 5. Результаты запроса на сайт, система кэширования не используется
Для того чтобы увидеть, что произошло с сервером, мы будем использовать отличный инструмент . Он предоставит нам нужные графики.
Рисунок 6. Данные, полученные с помощью NetData
IP тестового сервера Roubaix был занесен в белый список брандмауэра, чтобы фильтры не мешали тестам. Файл hosts был отредактирован для доступа к веб-сайту через брандмауэр.
Тест №2. Кэширование CDN — одно соединение
Теперь приведем результат той же команды, но используя Sucuri Firewall для обработки трафика и доставки контента.
Рисунок 7. Результаты той же команды, но с использованием Sucuri Firewall
Sucuri Firewall работает поверх встроенного CDN, поэтому, несмотря на то что сайт WordPress размещен в Лос-Анджелесе, большая часть контента поступает из центра данных Sucuri Frankfurt, что улучшает время отклика.
Рисунок 8. Использование ресурсов при включенном Sucuri Firewall
Из полученных результатов можно сделать вывод, что скорость увеличилась в два раза. Однако дело здесь не только в скорости, скорость — лишь верхушка айсберга.
Сталкиваемся с DoS-атакой
Мы продолжили использовать Siege, но в этот раз увеличили нагрузку на сервер. По сути, мы моделировали очень небольшую атаку типа Denial-of-Service (DoS). Следующие четыре теста имитировали 20 пользователей, одновременно зашедших на сайт.
Из-за нашей защиты от DDoS нам пришлось внести в белый список IP-адрес сервера. Это позволило убедиться, что брандмауэр Sucuri Firewall не блокирует стресс-тест. В нормальной конфигурации Sucuri Firewall обнаруживает ботоподобное поведение и быстро блокирует его, чтобы избежать любого повреждения на сервере веб-сайта.
Не стоить забывать о том, что из-за низкой стоимости и популярности DDoS вы рискуете столкнуться с более сложными и мощными атаками на свой сайт.
Тест №3. Отсутствие кэширования — 20 одновременных подключений
Теперь вместо одного условного пользователя попробуем запустить одновременно сразу 20.
Рисунок 9. Результат двадцати одновременных запросов на сайт, система кэширования не используется
Использование ресурсов было настолько большим, что NetData не удалось получить точные данные.
Рисунок 10. Данные NetData при двадцати одновременных запросах на сайт
Тест №4. Кэширование фаервола — 20 одновременных подключений
В четвертом тесте мы решили получить результаты при включенном брандмауэре, сделав также 20 одновременных запросов на сайт. Итак, редактируем файл hosts и смотрим на результаты.
Рисунок 11. Результат двадцати одновременных запросов на сайт при включенном фаерволе
Что же мы имеем согласно NetData. Думаете, сервер испытывает серьезные нагрузки? Совершенно нет.
Рисунок 12. Данные NetData при двадцати одновременных запросах на сайт и включенном фаерволе
Благодаря фаерволу время отклика уменьшилось с 3,69 секунды до 0,03 секунды. Следовательно, тест показывает увеличение количества переданных данных на 800%.
Плагины для кэширования
Возникает вопрос: можно ли добиться такого же результата, используя плагин для кэширования. Чтобы проверить это, мы установили популярный плагин (подобных результатов можно достичь и с помощью других плагинов).
Тест №5. Плагин для кэширования — 20 параллельных подключений
Теперь мы устанавливаем рекомендованные настройки WP Super Cache и проверяем, как отвечает сервер на 20 одновременных подключений.
Рисунок 13. Результат двадцати одновременных подключений при включенном плагине WP Super Cache
Тест показывает отличные результаты в сравнении с тем, когда кэш не использовался. С другой стороны, использование ресурсов по-прежнему слишком большое для 20 одновременных пользователей.
Рисунок 14. Данные NetData при двадцати одновременных запросах на сайт и включенном плагине WP Super Cache
Тест №6. Плагин для кэширования и брандмауэр — 20 параллельных подключений
В этом тесте мы объединили усилия брандмауэра и плагина для кэширования.
Рисунок 15. Результат двадцати одновременных подключений при включенном плагине WP Super Cache и брандмауэре
Как видно, существенного использования ресурсов не наблюдается. Сервер с легкостью справляется с нагрузкой.
Рисунок 16. Данные NetData при двадцати одновременных запросах на сайт, включенном плагине WP Super Cache и брандмауэре
Теперь перейдем к более ресурсозатратным тестам.
Тест №7. Плагин для кэширования и брандмауэр — 100 одновременных подключений
Увеличиваем количество одновременных подключений до 100, при этом задействуем WP Super Cache, смотрим на результаты.
Рисунок 17. Результат ста одновременных подключений при включенном плагине WP Super Cache
А вот что говорит NetData.
Рисунок 18. Данные NetData при ста одновременных запросах на сайт и включенном плагине WP Super Cache
Теперь то же самое, но вместо плагина используем фаервол.
Рисунок 19. Результат ста одновременных подключений при включенном фаерволе
Когда брандмауэр обрабатывал трафик, серверу гораздо легче работается.
Рисунок 20. Данные NetData при ста одновременных запросах на сайт и включенном фаерволе
Исходя из полученных данных можно сделать вывод, что фаервол всегда лучше обрабатывает трафик.
Выводы
Имейте в виду, что это была одноминутная HTTP-атака с одного IP-адреса на небольшой NGINX VPS. Представьте себе масштабы атаки с 50 тысяч IP-адресов в течение 24 часов. Результаты тестов указывают на то, что в реальных условиях содержания сервера лучше всего будет использовать фаервол, это избавит вас от головной боли.
