ИТ Блог. Администрирование серверов на основе Linux (Ubuntu, Debian, CentOS, openSUSE)
(1 оценок, среднее: 5,00 из 5)
Загрузка...
За последние несколько недель мы столкнулись с серьезными последствиями недавней миграции сервера на нашей большой установке 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 в будущем:
В целом, это был захватывающий набег в той части разработки, которую мы никогда не затрагивали, но в конце дня мы чувствуем себя разочарованным существующими вариантами тестирования нагрузки/производительности/стресса, особенно когда это связано в WordPress. Нам интересно, как другие люди справляются с этим?
