На чем потестить инструменты для нагрузочного тестирования

Apache Benchmark - это классика.

На локалхосте чем не? Но вообще для сайтов, а не апи, лучше jmeter'a врядли что найдется. Памяти разве что докинь

Для почасовой оплаты нужного количества ресурсов бери любое облако только помни о трафике.

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

Скажу тебе, как человек, серьезно занимавшийся нагрузочным тестированием. 1) забудь про ab, только tsung, jmeter и свои поделки (своих поделок бояться не надо! Главное - не забывать про профайлер) 2) Забудь про виртуалки. Для нормальных тестов нужен нормальный стенд. Т.е. несколько машин-источников нагрузки, лучше физических, нормальная сеть. В идеале - все в один свитч. Свой сервис обязательно на физической машине. 3) Когда упираешься в один показатель - нужно быть готовым его исключить - заменить hdd на ssd, поместить все на рамдрайв, воткнуть более мощный cpu и т.д. 4) Тебе сильно поможет dstat -lavr 5) Профайлер, профайлер и еще раз профайлер 6) Начинать стоит с G1 GC

а siege тоже плох?

Не использовал. Я не только и не столько вебом занимался. Судя по описанию - ничего особенного.

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

забудь про ab

А чем он плох? Я планировал использовать для задач навроде «1000 пользователей гетают главную, как это отразится на цели». Про tsung почитал, спасибо, интересный инструмент.

abсолютно бессмысленная статистика.

Да. Еще из хороших советов. Я уже говорил, но еще раз повторю - источники нагрузки должны быть способны выдать достаточную для твоих тестов нагрузку.

Это само собой разумеется.

ты пойми, у тебя 2 задачи на текущий момент: понять, какой порядок сценариев аппликуха сможет переварить, и понять, сколько железа тебе надо, чтобы добраться до нужной нагрузки. Если ты не имеешь расширяемого тестового енвайрмента - тебе строго дорога на локалхост и на рынок за памятью для жметра (насколько я помню, оно всегда упиралось именно в память)
Если есть тестовый енв - то хз. Можно пихать свои велосипеды - как тут прально сказали, не надо их бояться, или можно чужие велосипеды юзать типа httpunit и иже с ними.
Но у меня на самом деле стойкое ощущение что опять не того человека запрягли тестировать. Отсюда и глупые вопросы

Очень интересно, зачем человеку, который занимался тестированием, профайлер. Не учите мальчика плохому, у QC свои цели, у девов свои. Не надо мешать теплое с мягким

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

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

Все с нуля начинают.

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

Вот для этого я и провожу тестирование. Грубо говоря я посчитал что мой сайт выдержит 10 одновременных пользователей, а по факту он не выдерживает и пяти - дело в сайте. Если вижу что упираюсь в ресурсы машины с которой тестирую (по плану у меня 10 пользователей, а я дал 10 тысяч и все ОК, но хочу узнать максимум) - ясное дело нужно умощнять.

Если ты не имеешь расширяемого тестового енвайрмента - тебе строго дорога на локалхост и на рынок

Много разных средств для тестов, пока хочу так посмотреть - jmeter на моей машине может в 10 пользователей, а тот же ab на тот же кейс может выдавать 300 (ну абстрактно). Определившись с инструментом уже буду подгонять ресурсы под нужную нагрузку на сайт.

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

Наверное затем, чтобы не тестировать пропускную способность дедлока. Смотреть надо на то, что происходит в черном ящике, а то иногда такие глупые вещи случаются, что просто эх.

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

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

свой велосипед - всяко не черный ящик. а вот лезть тестировщику в то, что внутри черного ящика under test - лишняя трата времени, бессмысленная к тому же. затык по памяти/cpu/iops зафиксировали - все, репортаем и забываем пока его не починят.

на stoplinux.org.ru можно. Только потоков побольше заряжай.

свой велосипед - всяко не черный ящик

Видимо, ты никогда не напарывался на то, что, к примеру, энтропия заканчивается?

это ты к чему?

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

у тебя тотальные проблемы с изложением мыслей. какой софт? jmeter? самописный велосипед? тестируемый софт?

Самописный и тестируемый. jmeter давно уже отпрофайлен, за него можно не бояться. Хотя посмотреть жконсолью на активность гц может оказаться полезным.

Рейс кондишены и бутылочные горлышки могут оказаться в самых неожиданных местах.

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

Самописный и тестируемый

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

Реальный кейс:

byte[] md5(byte[] source) {
MessageDigest md = MessageDigest.getInstance("MD5");
return md.digest(source);
}

Используется для генерации чего-нибудь при каждом реквесте.

Вопрос: что будет тестировать QAшник?

Используется для генерации чего-нибудь при каждом реквесте.

чем используется епт? велосипедом или приложением

Приложением.

и в каком месте это роняет тест?

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

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

Нигде. Сразу отдается клиенту.

ну тогда мне в упор непонятно, как система, которая встанет колом на отправке такого реквеста, дошла до нагрузочного тестирования

Так она колом встанет на нагрузочном тестировании. А до того момента все будет хорошо и гладко. И только под профайлером вдруг станет видно, что 95% времени проходит внутри .getInstance()

Тесты? Компиляция тяжелых прог с максимальной нагрузкой на время. Либо любой benchmark-прога. Выше советовали Apache Benchmark.

так, а теперь для тех, кто с md5 и хэшами не работал? я так понял, ты намекаешь (вот кстати дурацкая привычка говорить полунамеками, все приходится клещами тянуть) что сервер, который юзает хэш как айдишник сообщения, ответ на которое надо вернуть, встает колом пытаясь отправить сообщение, когда случаются коллизии md5. судя по тому, что ты говоришь о getInstance, ты имел в виду не это. тогда что?

мальчик, уйди не мешай

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

Отключите интернет в кащенке.

давай в еще более простых терминах. в чем выражалось вставание системы колом и какие условия для этого нужны?

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

если вся проблема в том, что компонентное тестирование не предусматривало какой-то кейс (например взятые с потолка коллизии в прошлом моем примере) - вопрос к тестировщику, почему он не подумал об этом раньше и вообще довел систему до стадии нагрузочного тестирования

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

Нужна ошибка разработчика. Выражаться может в чем угодно. Например, высокая нагрузка на CPU и крайне низкая пропускная способность. Или низкая пропускная способность при отсутствии нагрузки на хост.

Или резкое падение пропускной способности при увеличении конкурентности.

ну тогда см. выше

Ох, уболтал. Все красиво и замечательно, тем не менее, тестирование человеком, понимающим как же софт работает внутри - более продуктивно. Я щитаю. Все, ви пгавы, я удаляюсь.

тестирование человеком, понимающим как же софт работает внутри

а еще лучше быть богатым и здоровым, чем бедным и больным :)

в 99% случаев тестировщик имеет технический бэкграунд хуже, чем девелопер. и на то, что могло вылиться в «тестовый прогон - багрепорт - отладка разработчиком - исправление в итоге 3 дня» выливается в «разбор кода - работа с профайлером - анализ кода - исправление ошибки - тестирование - исправление других ошибок в итоге неделя + надо наверстывать QAчные таски». мрачная реальность такова, что время whitebox-тестировщиков слишком дорого стоит, чтобы вешать на них еще и нагрузочное тестирование

Как-то вот получается, что один умный человек получается дешевле, чем три-четыре бибизяны. Дешево - не значит хорошо.

а смысл в том, что одним вы хрен обойдетесь. ну смотри, whitebox тестирование само по себе дольше, чем blackbox, + есть куча задач, типа написания кейсов, интеграционного тестирования, выполнения тестов, автоматизации той же, которые все равно нужно делать. и справиться с ней может и человек, который на порядок хуже понимает, что в программе происходит. а грамотное использование метрик покрытия кода и код ревью не для галочки вообще сводят whitebox тестирование к минимуму, и один человек вполне себе может парт-тайм дизайнить тесты в нескольких проектах параллельно (ну, условно, понятно, что никто не будет сказать с плюсов на пхп, оттуда на жабу а с жабы на руби. но в некоторых пределах можно)