MySQL: как измерить производительность сервера?

Тестирование (бенчмаркинг) MySQLВ предыдущей статье мы выяснили, для чего нужно проводить эталонное тестирование (бенчмаркинг) сервера 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 перейдем к практике (т. е. тактике) тестирования сервера.

 

Вас заинтересует / Intresting for you:

Модель развития базы данных My...
Модель развития базы данных My... 781 просмотров Ирина Светлова Thu, 10 Jan 2019, 12:29:03
Выбор оптимальных типов данных...
Выбор оптимальных типов данных... 3561 просмотров Валерий Павлюков Sun, 27 Oct 2019, 15:24:19
Обзор архитектуры MySQL
Обзор архитектуры MySQL 2086 просмотров Ирина Светлова Wed, 09 Jan 2019, 04:25:21
Транзакции в базе данных MySQL
Транзакции в базе данных MySQL 8344 просмотров Ирина Светлова Mon, 07 Jan 2019, 05:18:23
Войдите чтобы комментировать