За последние несколько недель мы столкнулись с серьезными последствиями недавней миграции сервера на нашей большой установке WordPress MU. Хотя перемещение всего должно дать нам более мощный набор инструментов, сэкономить на затратах и дать больше гибкости инфраструктуры, мы бы хотели, чтобы сокращение было беспрецедентным.
Однако после нескольких дней работы коммутатора мы столкнулись со сценарием, когда MySQL начал использовать доступную память на сервере. Очевидно, что это было неустойчиво, поэтому появилась идея заменить MySQL на MariaDB, что является улучшением для MySQL.
Мы подключили это к нашему промежуточному серверу, и это, похоже, сразу же выровняло производительность нашей базы данных. Однако мы хотели провести некоторое базовое нагрузочное тестирование этой новой установки, чтобы убедиться, что производительность останется такой же, как увеличилось наше использование.
После того, как этот новый уровень использования оставался стабильным в течение дня или около того, мы решили провести нагрузочное тестирование на обоих серверах, чтобы проверить некоторые из этих предположений. Как только мы приступили к этому, мы почувствовали, что существующие инструменты нагрузочного тестирования не дают нам отличной картины того, как наша установка может пострадать под нагрузкой.
Например, мы используем NGINX в качестве прокси для Apache, а NGINX отлично кэширует часто используемые ресурсы. Тем не менее, поскольку у нас есть очень много сайтов на этом мультисайте, мы не говорим о тоннах трафика на несколько популярных страниц; вместо этого мы рассматриваем новые загрузки на множестве различных сайтов, которые могут фактически повлиять на производительность SQL.
Когда NGINX отвечает кэшированной страницей или ресурсом, на самом деле ничего не доходит до MySQL вообще.
Поскольку большинство существующих инструментов нагрузочного тестирования позволяют вам сосредоточить внимание на трафике по нескольким URL-адресам, мы решили написать сценарий быстрого тестирования, который перебрал бы более крупный CSV-файл наших 100 самых популярных сайтов согласно нашим аналитическим данным.
Мы разместили содержание кода ниже:
import csv
import requests
import chardet
import time
def check_traffic():
while True:
with open('./page_urls.csv', 'rb') as csv_file:
result = chardet.detect(csv_file.read())
with open('./page_urls.csv', 'r', encoding=result['encoding']) as encoded_file:
rows = csv.reader(encoded_file)
for row in rows:
url = "http://test.andreyex.ru/" + row[0]
print("getting url: " + url)
r = requests.get(url)
res = {"url": url, "status_code": r.status_code, "test": r.text }
print(res)
time.sleep(.2)
check_traffic()
Этот быстрый скрипт отлично справился с задачей получения тонны запросов после кэширования NGINX на начальном этапе, что позволило нам оценить показатели производительности, которые нам были интересны на бэкэнде. Однако это был довольно ручной процесс входа на сервер через SSH, запуска команды top или htop, запуска нагрузочного теста через локальную командную строку, а затем отслеживания верхнего вывода в отдельном окне терминала.
Хотя это было полезно для наших конкретных целей, оно действительно показало нам, насколько далеко должны подняться некоторые инструменты нагрузочного тестирования с точки зрения их полезности, особенно для нестандартной настройки WP, как только вы избавитесь от заботы о задержке на одном URL.
В нашем заключительном обсуждении мы говорили о том, куда, по нашему мнению, должно пойти нагрузочное тестирование для WordPress в будущем:
- Простая установка плагина, позволяющая выполнять нагрузочное тестирование для создания постов, обновления постов, создания комментариев и загрузки медиа как часть нагрузочного теста. Для тех, кто использует WP MU в качестве платформы для разработки, когда вы достигнете определенного масштаба, считывания в вашей базе данных не будут самой большой проблемой, это когда у вас одновременно работают 1000 авторов, что вещи начинают двигаться в сторону.
- Любой, кто запускает большую установку WP, знает, что плагины и даже, возможно, темы не созданы и распределены одинаково. Таким образом, сосредоточение внимания на одном или двух основных URL-адресах может ввести нас в заблуждение относительно того, как работают другие сайты, возможно, менее под нашим прямым контролем.
- Фактически имитируйте трафик браузера, а не проверяйте задержку с помощью только исходного HTML-ответа. Например, инструмент loader.io отправляет 10 000 или более запросов на один и тот же URL-адрес и отслеживает время ответа для каждого запроса. Однако это не очень полезно для получения полной картины того, как ваш сайт будет реагировать при фактической нагрузке. Когда браузер анализирует ваш HTML, он запускает дополнительные запросы скриптов/стилей/ресурсов, которые будут загружать ваш сервер. С точки зрения передачи данных легко понять, почему компании, занимающиеся нагрузочным тестированием, не моделируют браузер. В нашем тесте с 500 клиентами общее потребление полосы пропускания для всех тестов составило где-то около 5 МБ, но когда мы рассчитали, что 500 клиентов загрузят весь вес страницы, полоса пропускания была где-то около 2,5 ГБ.
- В настоящее время кажется, что большинство инструментов тестирования производительности вовлекают в процесс больше клиентов, чем реалистичных, чтобы мы почувствовали, что все работает хорошо. Но для большинства из нас 10000 клиентов за 5 минут, загружающих одну кэшированную HTML-страницу, далеко не реалистичны. Мы считаем, что было бы здорово, если бы инструмент для нагрузочного тестирования мог интегрироваться с вашими данными Google Analytics, чтобы имитировать нагрузку, которая была бы реально напряженной для вашего приложения с использованием исторических данных.
В целом, это был захватывающий набег в той части разработки, которую мы никогда не затрагивали, но в конце дня мы чувствуем себя разочарованным существующими вариантами тестирования нагрузки/производительности/стресса, особенно когда это связано в WordPress. Нам интересно, как другие люди справляются с этим?
