Я занимаюсь созданием высоконагруженных приложений для биржевой торговли. Нагруженных как по объёму данных, так и по количеству пользователей и запросов. Естественно, что для таких приложений первостепенное значение имеет производительность, и, как следствие, тестирование оной.
Наблюдая со стороны это тестирование, я накопил некоторый объём информации, который, как я думаю, будет небезынтересен.
Камень 1-й. Коэффициент пересчёта
Тестирование таких приложений требует развёртывания целой сети тестовых машин. В итоге это приводит к образованию тестового кластера. Попытка развёртывания такого кластера на базе машин, физически стоящих в центре разработки, ведёт к созданию собственного датацентра со всеми издержками такого решения. Хорошей альтернативой стало использование решений типа Amazon Web Services.
Естественное желание сэкономить на аренде хостов или на покупке оборудования приводит к выбору таковых с заниженными относительно production инсталляции характеристиками. Заниженными в разы. И тут вступает в действие коэффициент пересчёта между синтетическими индексами производительности. Т.е. процессор в production будет в 2 раза быстрее, количество ядер будет в 4 раза больше, объём оперативной памяти будет в 6 раз больше, производительность дисковой подсистемы будет в 3,5 раза лучше, скорость сети будет в 100 раз больше. Сложим, поделим на количество показателей, умножим на некий поправочный коэффициент и получим коэффициент пересчёта, на который будем умножать результаты тестирования производительности. Можно придумать и более сложную формулу, например, назначить каждому показателю некий вес.
При ближайшем же рассмотрении такой подход оказывается пригодным лишь для подготовки тестовой сюиты для будущего тестирования на инсталляции, близкой к production, и на обнаружение самых очевидных проблем производительности. (Что уже достаточно много и важно.) Почему? Да потому хотя бы, что при таком подходе совершенно не учитывается эффект bottlenecks.Читать полностью »
