Нагрузочное тестирование на виртуалке. За и против.

вообще странно, почему этим вопросом задаешься ты, а не qa

А с другой стороны будут ли эти результаты соответствовать поведению программы на реальном железе?

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

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

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

С одной сторын у виртуалок можно объём ОЗУ и количество процессоров менять, создать слабую конфигурацию и загрузить её нагрузочным тестом до самого падения.

это не нагрузочное тестирование, а стресс-тестирование, которое решает совсем другие задачи.

А сейчас ещё остались люди, которые на голое железо ставят что-либо, кроме гипервизора? О_о

Сетевое нагрузочное тестирование только идиот прокручивает в виртуалках. Кроме исключения - сетевуху полностью пробрасывать в виртуалку через VT-d. Иначе результаты поразят разрабов и QA-отдел тоже.

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

Я не специалист по тестированию, но из вашего поста цель тестирования выглядит странно — уронить программу, а не проверить её работоспособность в различных дистрибутивах (библиотеках) или оценить её производительность.

ох уж эти не специалисты по тестированию
https://ru.wikipedia.org/wiki/Стресс-тестирование_программного_обеспечения#.D...

Дак под «падением» ТС подразумевал «падение производительности ниже требуемого уровня»?

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

Для этого всегда используется реальное железо и девы должны сразу заворачивать обратно баги по скалабилити, если сетап был развёрнут в виртуалке. Более того, в зависимости от проекта, база может быть на стороннем «железном» сервере.

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

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

Ничего они не должны.

Должны. И нормальные дэвы в нормальных конторах так и делают.

Проекты бывают разные, и если это не дикий хайлоад

Проекты все одинаковые, и если ты гонишь обычный смок-тест или регрешен, то просто тупо минимальные требования соблюдаешь, и всё. Хотя и тесты, включающие работу с меньшим объемом свободной памяти должны быть включены.

просто стоит задача оценить пределы производительности и найти узкие места - виртуалка неплохой вариант для тестирования

Да-да, оценивать производительность в виртуалке - это круто конечно. И что ты же ты замеришь? Ну вот что? Что используя виртуализацию X можно сервить 500 клиентов? А почему тогда не виртуализацию Y? И какие требования к железу ты потом напишешь?

Проекты все одинаковые, и если ты гонишь обычный смок-тест или регрешен

и при чем тут это? тестирование производительности - отдельный вид тестирования

И что ты же ты замеришь? Ну вот что?

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

и для такого прогона (а именно об этом, судя по всему говорит ТС, хотя вряд ли он знает, как потом дальше надо действовать) - тестировать можно хоть на виртуалке хоть на микроволновке.

С одной сторын у виртуалок можно объём ОЗУ и количество процессоров менять, создать слабую конфигурацию и загрузить её нагрузочным тестом до самого падения.

загадить память можно и без виртуалки. Да и вообще тестирование проводят на том железе, на котором оно будет работать IRL. (Или хотя-бы похожем, но тогда достоверность тестов под вопросом).

А с другой стороны будут ли эти результаты соответствовать поведению программы на реальном железе?

скорее всего нет.

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

jff разве что...

А сейчас ещё остались люди, которые на голое железо ставят что-либо, кроме гипервизора?

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

оценить пределы производительности

пределы в сферическом вакууме?

и найти узкие места

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

разница между «оценить» и «замерить» вам неведома?

Ведома. А еще мне ведома разница между голым железом и виртуализацией. Конкертно на моём проекте разница между разными системами виртуализации - разы. Поэтому мне непонятно, что можно оценить, даже приблизительно.

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

Это как? Замерить работу под нагрузкой с БД, с ФС, потом сетевую нагрузку, а всё вместе не замерить? Что это за бред получится?

пределы в сферическом вакууме?

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

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

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

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

Проекты бывают разные, и если это не дикий хайлоад

Проекты все одинаковые

Конкертно на моём проекте разница между разными системами виртуализации - разы.

ok, я понял

Это как? Замерить работу под нагрузкой с БД, с ФС, потом сетевую нагрузку, а всё вместе не замерить? Что это за бред получится?

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

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

нет, это проблема — тест должен выявить узкие места, и он «выявит», что у тебя проблема с памятью(со скоростью). А на самом деле, IRL с памятью всё в порядке, и это просто беда виртуализации. А ты три недели трахался оптимизируя доступ к памяти, который и так не плох.

проблема если ты пропустишь что-то, что может остаться проблемой и на реальном железе.

вот ты и пропустишь, т.к. увидишь что-то другое. У виртуалок Over9000 «особенностей», разве ты не в курсе? Т.е. там всё работает, но не так. Проблема ещё и в том, что это не так само по себе разное — в версии 6.6.7 пофиксили баг 6.6.6, из-зап которого ты думал, что у тебя проблема с памятью. Т.е. проблема «решается» просто с обновлением системы(или наоборот — появляется). Смысл в таких «тестах»?

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

так, наверное, и работают

на самом деле, нагрузку(загрузку) можно рассчитать. Если ты в курсе, как работает система, и понимаешь в алгоритмах, тебе будет не сложно прикинуть как будет расти загрузка в зависимости от нагрузки. Да, не очень точно, но всё же.

нет, это проблема — тест должен выявить узкие места, и он «выявит», что у тебя проблема с памятью(со скоростью). А на самом деле, IRL с памятью всё в порядке, и это просто беда виртуализации. А ты три недели трахался оптимизируя доступ к памяти, который и так не плох.

а нахера ты трахался оптимизируя доступ к памяти тогда, когда QA только планировал тестирование?

Смысл в таких «тестах»?

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

мне и дальше объяснять очевидное?

а нахера ты трахался оптимизируя доступ к памяти тогда, когда QA только планировал тестирование?

ну это уже какой-то другой вопрос, к вопросу ТСа отношения не имеет.

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

ну если у нас такая постановка вопроса, то да, согласен. Если никто нихрена не знает, то лучше хоть на виртуалке попробовать...

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

Сетевое нагрузочное тестирование только идиот прокручивает в виртуалках.

http://wanem.sourceforge.net/

не мешай дяденьке пилить бабло ☺

2 vostrik да, не о чем спорить.

ok, я понял

Что ты понял? Разница в разы даже во время установки ПО, а не в каких-то тестах под нагрузкой. Притом встречются ивестные проблемы. Например в WMVare в своё время была бага в работе с SQL. Отлавливать потом проблемы в работе софта из-за кривой виртуализации?

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

Оххх... Чувак, ты судя по всему далёк от QA, или гоняешь тесты на сайтах.

Что ты понял

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

Оххх... Чувак, ты судя по всему далёк от QA

как скажешь

или гоняешь тесты на сайтах.

написанных на убогоньком недоязычке. это важно.

нет не будут, виртуальное железо ведет себя иначе чем реальное.

ну и смотря какие вирт.машины использовать.