Конкретные способы тестирования MySQL на примере

Prev
Next »

Способы тестирования (бенчмаркинга) MySQLЗакончив с общими вопросами (зачем нужно тестировать сервер MySQL и стратегия измерения производительности), давайте перейдем к конкретике — к тому, как проек­тировать и выполнять эталонные тесты. Однако прежде, чем обсуждать, как правильно выполнять эталонное тестирование, рассмотрим распространенные ошибки, которые могут привести к неподходящим или неточным результатам.

  • Использование меньшего объема данных, чем требуется, например 1 Гбайт дан­ных, когда приложение должно будет обрабатывать сотни гигабайт. Или исполь­зование текущего набора данных, если предполагается, что приложение будет быстро расти.
  • Применение данных с неправильным распределением, например равномерно распре­деленных, если в реальных данных будут встречаться горячие точки. (Сгенерирован­ные случайным образом данные почти всегда имеют нереалистичное распределение.)
  • Использование нереалистично распределенных параметров, скажем, в предположе­нии, что профили всех пользователей будут просматриваться с одинаковой частотой.
  • Применение однопользовательского сценария для многопользовательского при­ложения.
  • Эталонное тестирование распределенного приложения на единственном сервере.
  • Несоответствие реальному поведению пользователя, например то, что не учиты­вается время обдумывания на веб-странице. Реальные пользователи запрашивают страницу, а потом читают ее, они не щелкают на ссылках без остановки.
  • Выполнение идентичных запросов в цикле. Реальные запросы не идентичны, так что они могут вызывать ошибки кэша. Идентичные запросы будут полностью или частично кэшированы на каком-то уровне.
  • Отсутствие контроля ошибок. Если результаты эталонного теста не имеют смыс­ла — например, медленная операция внезапно очень быстро заканчивается, — ищите ошибку. Возможно, вы просто протестировали, насколько быстро MySQL может обнаружить синтаксическую ошибку в запросе SQL! Возьмите за правило после выполнения теста проверять журнал ошибок.
  • Игнорирование проверки работы системы, когда она не прогрета, например сразу после перезагрузки. Иногда нужно знать, как быстро ваш сервер наберет полную мощность после перезагрузки, таким образом, потребуется специально проверить время разогрева. И наоборот, если вы предполагаете изучить производительность в нормальном режиме, имейте в виду, что при проведении эталонного тестирова­ния сразу после рестарта кэш будет не разогрет и результаты будут отличаться от полученных при разогретом кэше.
  • Использование установок сервера по умолчанию.
  • Тестирование выполняется слишком быстро. Учтите, что тест должен длиться некоторое время. Мы еще поговорим об этом позже.

Простое предотвращение этих ошибок поможет вам значительно улучшить качество результатов.

При прочих равных условиях необходимо стараться делать тесты настолько реалистич­ными, насколько это возможно. Однако иногда имеет смысл применять немного нере­алистичные эталонные тесты. Предположим, что приложение находится не на том же компьютере, где размещен сервер базы данных. Реалистичнее запустить эталонные тесты в той же конфигурации, но это добавит факторы, показывающие, например, насколько быстра сеть и какова ее загрузка. Эталонное тестирование производитель­ности на одном узле обычно проще и в некоторых случаях дает достаточно точные результаты. Вы должны сами решать, когда такой подход допустим.

 

Prev
Next »
Войдите чтобы комментировать