В предыдущей статье мы выяснили, для чего нужно проводить эталонное тестирование (бенчмаркинг) сервера MySQL. Существует две основные стратегии эталонного тестирования: можно тестировать приложение целиком или проверить лишь MySQL сервер. Мы назовем эти стратегии соответственно полностековым и покомпонентным эталонным тестированием. Есть несколько причин для измерения производительности приложения в целом вместо тестирования только MySQL.
- Вы тестируете все приложение, включая веб-сервер, код приложения, сеть и базу данных. Это полезно, поскольку вас интересует производительность не MySQL, а всей системы.
- MySQL не всегда является узким местом приложения, и полное эталонное тестирование позволяет это выявить.
- Только в процессе полного тестирования вы можете увидеть, как ведет себя кэш каждой части.
- Эталонные тесты хороши лишь в той степени, в какой они отражают реальное поведение приложения, чего трудно добиться при тестировании его по частям.
В то же время эталонные тесты приложения сложно создавать и еще сложнее правильно настраивать. Если вы плохо спроектируете эталонный тест, то можете принять ошибочное решение, поскольку полученные в этом случае результаты не отражают реального положения.
Однако иногда нет необходимости получать информацию обо всем приложении. Возможно, нужно просто выполнить эталонное тестирование MySQL, по крайней мере на начальном этапе. Такое эталонное тестирование полезно, если вы хотите:
- сравнить различные схемы или запросы;
- протестировать конкретную проблему, обнаруженную в приложении;
- избежать длительного эталонного тестирования, ограничившись коротким тестом, который позволит быстро внести изменения и измерить их.
Кроме того, эталонное тестирование MySQL полезно, когда вы можете выполнить запросы характерные для своего реального набора данных. Как сами данные, так и размер набора должны быть реалистичными. По возможности используйте мгновенный снимок фактических рабочих данных.
К сожалению, настройка реалистичного эталонного теста может оказаться сложной и трудоемкой задачей, поэтому, если сумеете получить копию рабочего набора данных, считайте себя счастливчиком. Но это может оказаться невозможным — например, вы создаете новое приложение, которым пользуются немногие и в котором еще недостаточно данных. Если вы хотите знать, как оно будет работать, когда увеличится, то у вас нет другого выхода, кроме как сгенерировать больший объем данных и значительную нагрузку.
Что измерять. Перед началом эталонного тестирования нужно определить цели — собственно, это следует сделать даже до начала проектирования тестов. Цели определят инструменты и технику, которые вы будете использовать для получения точных осмысленных результатов. Постарайтесь сформулировать цели в виде вопросов, например: «Лучше ли этот процессор, чем тот?» или «Будут ли новые индексы работать эффективнее, чем нынешние?».
Иногда для измерения разных показателей требуются различные подходы. Так, нельзя определить сетевые задержки и пропускную способность с помощью одних и тех же эталонных тестов.
Рассмотрим следующие показатели и обсудим, как они соответствуют вашим.
- Пропускная способность. Определяется как количество транзакций в единицу времени. Это один из классических эталонных тестов приложений баз данных. Стандартизованные эталонные тесты, такие как ТРС-С (см. http://www.tpc.org), применяются часто, и многие производители баз данных активно работают над улучшением характеристик своих продуктов, определяемых с их помощью. Эти эталонные тесты измеряют производительность оперативной обработки транзакций (OLTP) и лучше всего подходят для интерактивных многопользовательских приложений. Общепринятой единицей измерения является количество транзакций в секунду, хотя иногда указывают и транзакции в минуту.
- Время отклика или задержки. Этот показатель определяет общее время выполнения задачи. В зависимости от приложения вам может потребоваться измерить время в микро- или миллисекундах, секундах или минутах. Отсюда можно определить среднее, минимальное и максимальное время отклика, а также процентили. Максимальное время отклика редко бывает полезно, поскольку чем дольше эталонный тест работает, тем выше, скорее всего, будет этот показатель. Кроме того, его невозможно повторить, так как значение наверняка будет сильно варьироваться при разных прогонах теста. По этой причине обычно используют время отклика в процентилях. Например, если время отклика составляет 5 миллисекунд с 95-м, значит, в 95 % случаев задача будет выполнена за 5 миллисекунд или быстрее. Обычно имеет смысл представить результаты эталонных тестов графически: либо в виде линейного графика (например, среднее и 95-й процентиль), либо в виде диаграммы разброса, на которой видно, как распределены результаты. Эти графики показывают, как будут вести себя эталонные тесты при длительных испытаниях.
- Параллелизм (конкурентный доступ). Параллелизм является важным показателем, но его часто неверно толкуют и плохо применяют. Например, число пользователей, просматривающих сайт в конкретный момент, обычно измеряется количеством сеансов. Однако в протоколе HTTP нет сохранения состояния, и если большинство пользователей просто читают содержимое страницы, открытой в браузере, это не вызывает параллелизма на веб-сервере. Аналогично, параллелизм на веб-сервере не обязательно означает параллелизм в базе данных. Единственное, что непосредственно связано с параллелизмом, — это объем данных, с которым должен справляться механизм хранения сеансов. Более точный показатель параллелизма на веб-сервере — это количество одновременных запросов в любой момент времени.
Кроме того, вы можете измерять параллелизм в различных местах приложения. Более высокий параллелизм на веб-сервере может вызвать более высокий параллелизм на уровне базы данных, однако на него могут повлиять также язык программирования и набор используемых инструментов. Убедитесь, что вы не путаете открытые соединения с сервером базы данных с параллелизмом. Хорошо спроектированное приложение может иметь сотни открытых соединений с сервером MySQL, но только часть из них будут выполнять запросы одновременно. Таким образом, сайт с «50 000 посетителей одновременно» может требовать только 10 или 15 одновременно выполняющихся запросов к серверу MySQL!
Иными словами,-при эталонном тестировании следует озаботиться рабочим параллелизмом, то есть количеством потоков или соединений, работающих одновременно. Измерьте, не падает ли производительность, не увеличивается ли время отклика при возрастании параллелизма. Если это так, то ваше приложение вряд ли сможет выдерживать всплески нагрузки.
Параллелизм — это показатель, кардинально отличающийся от других, таких как пропускная способность и время отклика. Обычно это не результат, а скорее свойство вашего эталонного теста. Вместо измерения уровня параллелизма, которого достигает ваше приложение, вы обычно просите инструмент эталонного тестирования сгенерировать различные уровни параллелизма и определяете производительность приложения в таких условиях. Однако вы также должны измерить параллелизм в базе данных. Когда запустите sysbench с 32,64 и 128 потоками, проверьте сервер базы данных во время каждого прогона и запишите значение переменной состояния
Threads_running. - Масштабируемость. Измерение масштабируемости полезно для систем, в которых необходимо поддерживать уровень производительности в условиях меняющейся нагрузки.
Сейчас дадим короткое определение масштабируемости. Идеальная система должна выполнить в два раза больше работы (соответственно в два раза увеличится пропускная способность), если вы удвоите число работников, пытающихся выполнить задачу. Вторая точка зрения на ту же проблему состоит в том, что если вы удвоите доступные ресурсы (например, используете вдвое больше процессоров), то сможете добиться удвоенной пропускной способности. В обоих случаях также требуется, чтобы производительность (время отклика) была приемлемой. Но большинство систем не являются линейно масштабируемыми и демонстрируют уменьшающуюся отдачу и ухудшение производительности при изменении параметров.
Измерение масштабируемости полезно для планирования пропускной способности, поскольку оно может показать слабые места в вашем приложении, которые не будут видны при других стратегиях эталонного тестирования. Например, если вы спроектировали свою систему для наилучшего выполнения эталонного теста времени отклика с одним соединением (это не лучшая стратегия эталонного тестирования), приложение может плохо работать при другом уровне параллелизма. Эталонный тест, который измеряет последовательное время отклика при увеличивающемся числе подключений, выявит этот недостаток проектирования.
Некоторые действия, такие как работа в пакетном режиме для создания сводных таблиц из детализированных данных, требуют короткого времени отклика. Необходимо выполнить их эталонное тестирование на время отклика, но при этом не забыть продумать, как они будут взаимодействовать с другими сеансами. Пакетные задания могут негативно повлиять на интерактивные запросы, и наоборот.
В конечном счете, лучше всего провести эталонное тестирование того, что важно для пользователей. Попытайтесь определить некоторые требования (формально или неформально): каково приемлемое время отклика, какой уровень параллелизма ожидается и т. д. Затем попробуйте спроектировать свои тесты для удовлетворения всех требований, избегая туннельного видения, то есть не сосредотачиваясь на одних моментах и исключая других.
Теперь от теории (стратегии) тестирования базы данных MySQL перейдем к практике (т. е. тактике) тестирования сервера.
