вторник, 26 октября 2010 г.

Конфигурация тестового стенда для нагрузочного тестирования

Введение


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


Содержание

  1. Конфигурация vs Производительность
  2. Конфигурация тестового стенда
  3. Анализ результатов при разных конфигурациях
  4. Выводы
  5. Литература


Конфигурация vs Производительность


На результаты нагрузочного тестирования могут влиять разные факторы, такие как конфигурация тестового стенда, загруженность сети, заполненность базы данных и многие другие. Причем влияние их на производительность приложения может быть значительным и иметь нелинейную зависимость, поэтому выразить её формулой будет практически невозможно. Следовательно, чем меньше будут разниться параметры тестовой и реальной инфраструктуры, тем меньше будет погрешность в полученных результатах.


Конфигурация тестового стенда


Отметим те части конфигурации, которые требуют особого внимания:

  • Hardware
    • процессор (тип, частота, количество ядер и т.д)
    • оперативная память (тип, объем, тайминг, эффективная частота и т.д.)
    • жесткие диски (тип, скорость и т.д.)
  • Software
    • Операционная система
    • Драйвера
  • Network
    • топология сети
    • пропускная способность
    • протокол передачи данных
  • Application
    • Архитектура
    • База данных (структура + данные)
    • программное обеспечение, необходимое для работы приложения (например, для Java приложений - JVM)

В самом идеальном случае тестовый стенд один к одному дублирует конфигурацию реального сервера, на котором работает или же будет работать приложение. Однако, как мы с вами знаем, идеальных случаев практически не бывает (то памяти мало, то процессора такой частоты нет в наличии, то операционная система не той версии, то стоимость некоторого серверного ПО не укладывается в бюджете). Перечислим основные причины, по которым не всегда получается продублировать конфигурацию системы на тестовом стенде:

  1. Сложность дублирования дорогого серверного железа для тестовых нужд
  2. Ограничения на использование лицензий требуемого программного обеспечения
  3. Закрытость архитектуры приложения со стороны заказчика по соображениям безопасности
  4. Трудность воссоздания или транспортировки базы данных приложения
  5. Сложность воссоздания требуемой архитектуры сети
  6. и многое другое (всё перечислить крайне сложно из-за большого количества нюансов, влияющих на конфигурацию системы)

Целесообразность же воссоздания инфраструктуры необходимо оценить с учетом выделенных ресурсов, времени и усилий, так как не всегда результат будет оправдывать средства.

Приведем пример (придуманный из головы и вполне возможно нереальный) для того, чтобы показать сложность сравнения результатов на двух разных системах:

Требуется конфигурация: Proc Intel Clarkdale Core I5, 16 Gb памяти DDR3-800, OS SLES11

Конфигурация тестового стенда: Proc AMD Deneb Phenom II X4, 16 Gb DDR2-800, OS SLES10

Казалось бы отличия незначительны, однако есть нюансы:

  1. Разные типы процессоров
  2. Разный тип памяти
  3. Разные версии операционной системы

Итак:

Cравним процессоры [3]:

Название ядра Intel Clarkdale Core I5 AMD Deneb Phenom II X4
Тактовые частоты, Мгц 2800-3600 2800-3000
Частоты системной шины, Мгц 2500 2000-1800
Пропускная способность шины процессор-чипсет 2 ГБ/сек (1 ГБ/сек в одном направлении) 14.4-16 ГБ/сек (7.2-8 ГБ/сек в одном направлении)
Размер кэша L1, Кб 64 х2 128 х4
Размер внутреннего кэша L2, Кб 256 x2 512 х4
Ширина шины L2 кеша, бит 256 (двунаправленная) 256 (по 128 в каждом направлении)
... ... ...

Примечание: Неправда ли, не просто будет сравнивать без помощи специалистов? Тем более вывести коэффициент на сколько какой процессор быстрее и по каким параметрам.

Cравним память [4]:

Стандартная задержка (latency) типичная для DDR2 5-5-5-15, а для DDR3 памяти 7-7-7-15. Однако даже с большей задержкой DDR3 память (в отличие от старого стандарта DDR2) обладает большей пропускной способностью (bandwidth) из-за более высокой тактовой частоты (clock speed). Что становится причиной того, что DDR3 память работает немного медленнее, чем DDR2 с такой же частотой 800MHz.

Таким образом, память на тестовом стенде будет немного быстрее чем в требуемой конфигурации.

Cравним операционные системы

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

Таким образом предположим, что SLES 11 будет незначительно быстрее SLES 10.

Удивлены таким большим количеством различий? (Причем это только для трех элементов конфигурации: процессора, памяти и операционной системы. В реальности их намного больше) Легко ли будет сделать выводы о том, как будет работать приложение на требуемой конфигурации? (Я думаю, что практически невозможно) Однако далее мы попробуем все таки найти пути для решения этой проблемы, рассмотрев некоторые практические приемы.

Анализ результатов при разных конфигурациях

Как же быть с тем фактом, что приложение будет протестировано на одной платформе, а работать ему придется на другой? Как провести анализ результатов? Как сделать окончательные выводы и спрогнозировать работу приложения под нагрузкой в будущем?

Использование переходного коэффициента

В своей статье [1] Вячеслав Берзин, предложил при анализе результатов использовать “переходный коэффициент”, показывающий численно отличие производительности тестовой платформы от промышленной:

"Если существует отличие в конфигурациях тестового стенда и тестируемой системы, необходима оценка переходного коэффициента для производительности тестовой и промышленной систем. На основании этого коэффициента, проводится масштабирование полученных результатов. Для получения погрешности оценки, не превышающей 5-10%, рекомендуется проведение оценки переходного коэффициента несколькими независимыми способами, например, на основании анализа независимых данных о производительности используемых аппаратных платформ."

Использование данного подхода, значительно облегчает создание и конфигурацию тестового стенда, но прибавляет работы на этапе анализа результатов. Так что вам придется решать самим: либо пытаться один к одному (100%) скопировать промышленную систему, либо сделать её максимально приближенной и с помощью переходного коэффициента анализировать и делать прогнозы на будущий рост производительности.

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

Использование экспертной оценки

Рассмотрим мнение Андрея Широбокова [2] (сертифицированный специалист в области нагрузочного тестирования, имеющий более 15 лет рабочего опыта в IT):

"Идеально ключевые моменты должны совпадать, пишу по убыванию важности:

  1. конфигурация (кол-во и тип процессоров х память)
  2. версия ОС и статс паки
  3. версия и тип СУБД
  4. версия серверов приложений и патчей

Естественно, что версия тестируемого приложения должна быть актуальна.

Если совпадает платформа (ОС и тип процессоров), то допускается "пропустить" конфигурацию, например, в случае если проведены эксперименты на конфигурациях 8х16 (8 прц х 16 Гб) и 32х64 (32 прц х 64 Гб), то можно "аппроксимировать" недостающую конфигурацию 24х48 (24 прц х 48 Гб). Обратим внимание, что памяти для такой методики должно пропорционально быть в 2 раза больше во всех случаях.

Если не совпадает платформа, ОС, типы процессоров, объемы памяти, то можно делать только очень общие выводы, наподобие: "В реальности будет не хуже". Но времена откликов и другие детали могут быть малозначимы."

Как видим, как при использовании переходного коэффициента, так и при использовании экспертной оценки, анализ результатов и прогнозирование роста производительности при тестировании на разных конфигурациях стендов (тестового и реального) становится затруднительным, и либо требует дополнительных перерасчетов по сложным нелинейным формулам с большим количеством параметров, либо не обеспечивает должной точности результатов.

Выводы

В данной статье мы попытались описать основные моменты связанные с конфигурацией тестового стенда для нагрузочного тестирования. В результате мы имеем следующее:

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

Литература

  1. Технология нагрузочного тестирования информационных систем с большим объемом данных , Вячеслав Берзин, Oracle Magazine, [01.12.04]
  2. Блог Андрея Широбокова (http://ashirobokov.blogspot.com)
  3. Сравнение характеристик процессоров
  4. DDR3 RAM and DDR2 Memory Comparison

Информация взята с сайта Про Тестинг: Статья "Конфигурация тестового стенда для нагрузочного тестирования"

Отправить комментарий

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.