Эталонное тестирование (бенчмаркинг) является важным навыком как для новичков MySQL, так и для опытных пользователей. Проще говоря, эталонное тестирование — это создание рабочей нагрузки, предназначенной для того, чтобы подвергнуть систему стрессу. Основная его цель — изучение поведения системы, однако имеются и другие важные причины для выполнения эталонного тестирования, такие как воспроизведение желаемого состояния системы или испытание на отказ нового оборудования. В этой главе мы рассмотрим причины, стратегии, тактику и инструменты эталонного тестирования MySQL и приложений на базе MySQL. Особый упор сделаем на sysbench, потому что это отличный инструмент для эталонного тестирования MySQL.
Зачем нужно эталонное тестирование
Почему эталонное тестирование так важно? Дело в том, что его очень удобно и эффективно использовать для получения ответа на вопрос, что происходит, когда вы заставляете систему работать. Эталонное тестирование может помочь вам понаблюдать за поведением системы под нагрузкой, определить ее пропускную способность, узнать, какие изменения важны, или посмотреть, как приложение работает с разными данными. Эталонное тестирование позволяет создавать вымышленные обстоятельства в дополнение к реальным условиям, с которыми вы можете столкнуться. С его помощью вы можете:
- подтвердить свои предположения о системе и посмотреть, насколько они реалистичны;
- воспроизвести нежелательное поведение системы, которое вы пытаетесь устранить;
- измерить производительность приложения. Если вы не знаете, как быстро оно работает в данный момент, то не можете быть уверены в целесообразности изменений. Также вы можете использовать результаты предыдущих тестов для диагностики неожиданных проблем;
- имитировать нагрузку, превышающую ту, которую испытывает система сейчас, для определения узкого места масштабирования, с которым вы столкнетесь в первую очередь, когда она начнет расти;
- планировать рост системы. Эталонные тесты могут помочь вам оценить, какие оборудование, пропускная способность сети и другие ресурсы вам понадобятся для эмуляции будущей нагрузки. Это поможет уменьшить риски при модернизации или серьезных изменениях приложения;
- проверить, способно ли приложение работать в изменяющихся условиях. Например, вы можете узнать, как оно работает во время единичного пика одновременно работающих пользователей или при другой конфигурации серверов. Или увидеть, как оно обрабатывает другое распределение данных;
- проверить различные конфигурации оборудования, программного обеспечения и операционной системы. Что лучше для вашей системы — RAID 5 или RAID 10? Как изменяется производительность произвольной записи при переключении с дисков АТА на хранилище SAN? Лучше ли масштабируется ядро Linux 2.4, чем ядро Linux 2.6? Увеличит ли производительность обновление версии MySQL? Что будет, если использовать другой механизм хранения данных? Вы можете ответить на эти вопросы с помощью специальных эталонных тестов;
- убедиться, что недавно приобретенное оборудование настроено правильно. Мы не можем сказать, сколько раз использовали эталонные тесты для испытания на отказ новой системы и обнаруживали неправильную конфигурацию или неисправные аппаратные компоненты. Не стоит запускать новый сервер, не проведя на нем эталонного тестирования и полагаясь лишь на слова провайдера или изготовителя оборудования о том, что установлено и как быстро оно должно работать. Тестирование, когда оно возможно, всегда полезно.
Кроме того, вы можете использовать эталонное тестирование для других целей, таких как создание набора ориентированных на конкретное приложение модульных тестов. Однако здесь мы сосредоточимся только на аспектах, связанных с производительностью.
Проблема с эталонным тестированием состоит в том, что оно ненастоящее. Нагрузка, которую вы используете, чтобы подвергнуть систему стрессу, обычно не дотягивает до реальной. Причина этого состоит в следующем: реальные рабочие нагрузки являются недетерминированными, варьирующимися и слишком сложными для понимания. Если вы проводите эталонное тестирование системы с реальной нагрузкой, по его итогам труднее будет сделать точные выводы.
В чем же нагрузка эталонного тестирования нереалистична? Существует множество искусственных показателей для эталонного теста: размер данных, распределение данных и запросов, но самое главное то, что эталонный тест обычно выполняется так быстро, как только возможно, загружая систему настолько сильно, что она показывает себя с худшей стороны. Во многих случаях хотелось бы заставить инструменты эталонного тестирования работать как можно быстрее, но с определенными оговорками, с возможностью останавливаться при необходимости, чтобы поддержать хорошую производительность. Это было бы особенно полезно для определения максимальной производительности системы. Однако большинство инструментов эталонного тестирования не поддерживает такую возможность. Лучше не забывать, что используемые инструменты налагают ограничения на значимость и полезность полученных результатов.
Непросто использовать эталонные тесты и для планирования вычислительных мощностей. Результаты эталонных тестов зачастую невозможно экстраполировать. Например, предположим, что вы хотите знать, какой рост бизнеса сможете поддерживать с помощью нового сервера базы данных. Вы проводите эталонное тестирование существующего и затем нового сервера и обнаруживаете, что он может выполнять в 40 раз больше транзакций в секунду. Но это не означает, что, используя новый сервер, ваш бизнес тоже сможет увеличиться в 40 раз. К тому времени, когда выручка настолько вырастет, система, вероятно, будет иметь больше трафика, больше пользователей, больше данных и больше взаимосвязей между различными частями данных. Не следует ожидать, что все эти факторы вырастут только в 40 раз, особенно это касается количества взаимосвязей. Кроме того, к этому моменту ваше приложение почти наверняка изменится: появятся новые функции, часть из которых могут влиять на базу данных далеко не пропорционально их кажущейся сложности. Эти изменения рабочей нагрузки, данных, взаимосвязей и функций очень трудно имитировать, а их воздействие сложно спрогнозировать.
В результате мы обычно соглашаемся на приблизительные результаты, чтобы узнать, есть ли у системы достаточное количество резервных мощностей. Можно выполнить более реалистичное тестирование нагрузки, отличающееся от эталонного, но это требует больше внимания при создании набора данных и рабочей нагрузки. И все же это не настоящий эталонный тест. Эталонные тесты проще, лучше сопоставимы друг с другом, дешевле и проще в управлении. И несмотря на их ограничения, эталонные тесты полезны. Вы просто должны четко понимать, что делаете и какой смысл в полученном результате.
Теперь давайте рассмотрим Стратегии эталонного тестирования MySQL.
