Сообщений в теме: 45

[Green]

Я отталкиваюсь от определения нагрузочного тестирования, которое предлагает RUP:
Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Как видим response times и transaction rates вообще вынесено в дополнения, но никак не ложится в основу.

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


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

Во-вторых, слово additionally тут совсем не к месту, так как именно эти параметры используются для описание поведения системы под нагрузкой.

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

[SALar]

Я отталкиваюсь от определения нагрузочного тестирования, которое предлагает RUP:
Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

Как видим response times и transaction rates вообще вынесено в дополнения, но никак не ложится в основу.

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


Кстати, совершенно правильное определение.

Господа, а причем тут Load testing, то бишь нагрузочное тестирование? В обсуждаемой статье и всем этом треде говорилось только о тестировании производительности, то бишь performance testing. То, что в у нас эти два понятия регулярно путают - проблема терминологии.

Нагрузочное тестирование имеет совершенно другие цели и проводится совершенно по другому: http://forums.softwa...owentry&eid=227

[Green]

Господа, а причем тут Load testing, то бишь нагрузочное тестирование? В обсуждаемой статье и всем этом треде говорилось только о тестировании производительности, то бишь performance testing. То, что в у нас эти два понятия регулярно путают - проблема терминологии.

Нагрузочное тестирование имеет совершенно другие цели и проводится совершенно по другому: http://forums.softwa...owentry&eid=227

Ох... Опять писать...
Давно уже я так много не писал.


В моей личной (а может быть и не личной, не помню откуда я взял эту классификацию, может быть даже с прошлого места работы ) классификации типов тестирования в нагрузочное тестирование входят следующие:
- нагрузочное тестирование, как таковое (performance or load testing)
- стрессовое тестирование (stress testing)
- тестирование наработки на отказ (reliability testing)
- тестирование масштабируемости (scalability testing)

Почему я их объединяю в одну категорию?

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

Все модели можно разделить на две категории: однопользовательские и многопользовательские.

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

Например,
для performance/load теста используется набор скриптов со средним уровнем нагрузки, а для stress теста - тот же самый набор, но с уровнем нагрузки выше максимально допустимого на 50%.

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

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

[Green]

В более тонкие материи типа "слоев нагрузки" предлагаю пока не влазить, чтобы окончательно не уйти "на глубину", если "на мелководье" не договорились зачем лезем :)

А кстати, Case,

что такое "слои нагрузки"?
Раньше мне не приходилось сталкиваться с этим термином.

[Satin]

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

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

Приведите примеры.

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

Фраза построена неудачно и допускает множественное толкование. Боясь, я ее просто не понял.
Кстати, а если это не новая версия, а просто новый продукт?

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

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

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

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

Первое, что приходит в голову — это сравнить средние значения утилизации ресурсов (например, CPU на сервере баз данных). И это правильно!

Присоединюсь к коллегам. Это неправильно.

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

[Satin]

На помощь приходит статистика.

Прошу прощения за резкость, но посмотрите вот этот материал: http://rsdn.ru/artic...Towrite.xml#ELD
-------------------------------------------------------------
Я не рекомендую читателям нашего сайта использовать статистические методы этой статьи в своей работе ввиду наличия ряда логических и фактических ошибок.

Сергей, просить прощения не обязательно. Важнее аргументировать свои суждения, особенно такие резкие.

Пожалуйста, перечислите ошибки применения мною статистики.

Вы возражаете против адекватности представления распределения нагрузки как полигона частот? Или Вас применение t-теста смущает?

Другой статистики вроде бы не было...

[Clauster]

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

ой-ёй-ёй

[Case]

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

что такое "слои нагрузки"?
Раньше мне не приходилось сталкиваться с этим термином.

Самое смешное, что я сам не могу найти первоисточник. По-моему в бытность мою сотрудником UMC (MTC) я перед внедрением Load Runner-а самостоятельно проходил внутренний курс (кажется какой-то британской школы), где толково была раскрыта тематика нагрузочного тестирования.

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

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

PS
Я думал, про слои "все в курсе" Просто оговорился про метод, чтобы очертить рамки обсуждения. Мы не знаем границ своих знаний. Представляю, сколько всего знаете ВЫ, чего не знаю я.

PPS
Два слова в блоге: Я хочу конференций и круглых столов

[Case]

Отличие наших позиций заключается только в растановке приорететов.

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

[Case]

Я отталкиваюсь от определения нагрузочного тестирования, которое предлагает RUP...

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

Совершенно согласен. Я не догматик, а RUP сам по себе не Догма. Но я пытаюсь отталкиваться от чего-то если не общепризнанного, то как минимум распространённого: чтобы дальше говорить на одном языке как минимум. Я тоже не кладу РУПовское определение полностью в основу своего понимания задачи нагрузочного тестирования, я включаю и решение задач масштабирования, наработки на отка и стрессы Системы. Я как раз и не беру полностю РУП с его масимализмом в этом аспекте (сколько будет ответ при максимальной нагрузке) а решаю реальные задачи, которые в основном спрашивают про пользователей.

Например, если система позволяет обработать одному операционисту из 300 только 100 заявок в день, то 101...120 пассажиры просто не получат свои билеты и самолёт улетит без них. Я выношу фокус на количество пользователей и бизнес требования, иначе мой ответ "Супер, 3 секунды на поиск одной записи!" будет проглочен Заказчиком как положительный результат тестирования и неприятности вылезут уже когда операционист будет производить реальные транзакции в Системе.

[Case]

И для малых и для сверхмалых проектов эта необходимость есть.

Приведите примеры.

Я приводил в вашем корп.Блоге.

Навскидку вот ещё пример.
Решаем как архитектурно работать с третьей системой: API или нативными методами. Реализуется разными методами доступ и тестируется на производительность (сколько яблок в минуту...) и на отказ (через сколько тонн яблок транспортёт скажет "хватит с меня"): при этом профилируем, замеряем, смотрим ресурсы. Это даже не проект, а скорее обычная задача: 1 девелопер на 1 день кодинга и может до недели на тестирование с подготовкой данных и анализом результатов.

Размер проекта не главное.

[Case]

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

Ну и что? А если добавлена логика, которая естественно из задачи будет потреблять больше ресурсов, тогда как?

[Satin]

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

Ну и что? А если добавлена логика, которая естественно из задачи будет потреблять больше ресурсов, тогда как?

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

"К черту фунциональность!", если она сделает систему недоступной для использования.

[Satin]

И для малых и для сверхмалых проектов эта необходимость есть.

Приведите примеры.

Я приводил в вашем корп.Блоге.

Навскидку вот ещё пример.
Решаем как архитектурно работать с третьей системой: API или нативными методами. Реализуется разными методами доступ и тестируется на производительность (сколько яблок в минуту...) и на отказ (через сколько тонн яблок транспортёт скажет "хватит с меня"): при этом профилируем, замеряем, смотрим ресурсы. Это даже не проект, а скорее обычная задача: 1 девелопер на 1 день кодинга и может до недели на тестирование с подготовкой данных и анализом результатов.

Размер проекта не главное.

Пример понятен, но непонятно, зачем "малому" проекту проверять, сколько яблок в минуту, если яблоки завозят раз в год по одному. В чем целесообразность?

Если возникла необходимость измерять "пропускную способность", значит проект не маленький. "Размер" я определяю как количество пользователей, операций и т.д. Как правило, это количество коррелирует с бюджетом проекта.

[SALar]

Если возникла необходимость измерять "пропускную способность", значит проект не маленький. "Размер" я определяю как количество пользователей, операций и т.д. Как правило, это количество коррелирует с бюджетом проекта.

У нас разные понятия размера проекта. Для меня крупный проект это примерно:
* от 1000 человеко месяцев
* от миллиона строк кода
* от 10 млн $ бюджет

[SALar]

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

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

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

Я имел ввиду, что фразу лучше разбить на несколько более мелких. Это ошибка подачи материала. В форуме объяснять значение не обязательно. Лучше поправить статью.

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

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

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

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

Просто для справки. Есть две основные проверки ПО: валидация и верификация. Вы произвольным образом установили в качестве требований к ПО некие показатели.
И по ним проводите верификацию. Это приводит к удорожанию проекта.
И не проводите валидацию. Это... Ну плохо это.

[SALar]

В моей личной (а может быть и не личной, не помню откуда я взял эту классификацию, может быть даже с прошлого места работы  ) классификации типов тестирования в нагрузочное тестирование входят следующие:
- нагрузочное тестирование, как таковое (performance or load testing)
- стрессовое тестирование (stress testing)
- тестирование наработки на отказ (reliability testing)
- тестирование масштабируемости (scalability testing)

Меня всегда смущало что performance и load testing:
1) Фигурируют как отдельные термины
2) Имеют разные определения
3) По разному проводятся

Из чего я сделал вывод, что это разные виды, преследующие разные цели.
Т.е. не performance or load, а performance and load.

[SALar]

Пожалуйста, перечислите ошибки применения мною статистики.

Распределение нагрузки новой версии отличалось большим разбросом значений, от 0 до 50%, в то время как текущая версия показала более цельный и организованный характер.

Принять решение о внедрении системы с такими показателями было бы самоубийственным,

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

Это неверно.

Прикрепленные файлы

•  ______________________.PNG   15,95К   106 Количество загрузок:

[SALar]

Есть некоторая вероятность (P = 0.0469) того что средние значения при бесконечном количестве измерений (в пределе) окажутся равны.

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

Чтобы уверенно судить о различии или идентичности средних распределений нагрузки нужно использовать t-критерий Стьюдента,

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

Далее:
* Перед проведением статистического исследования фиксируют критерии. Иначе все это исследование - лажа или подтасовка результатов. См. современные методы проведения аудита.
* Размер выборки влияет на результат. Отсутствие указания числа экспериментов в отчете означает лажу или подтасовку результатов. См. современные методы проведения аудита и статистические методы.

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

---------------------------------
Если бы статья называлась "Такие отчеты нравятся нашим клиентам!" то никаких претензий бы не было.

[Green]

В моей личной (а может быть и не личной, не помню откуда я взял эту классификацию, может быть даже с прошлого места работы  ) классификации типов тестирования в нагрузочное тестирование входят следующие:
- нагрузочное тестирование, как таковое (performance or load testing)
- стрессовое тестирование (stress testing)
- тестирование наработки на отказ (reliability testing)
- тестирование масштабируемости (scalability testing)

Меня всегда смущало что performance и load testing:
1) Фигурируют как отдельные термины
2) Имеют разные определения
3) По разному проводятся

Из чего я сделал вывод, что это разные виды, преследующие разные цели.
Т.е. не performance or load, а performance and load.

С радостью соглашусь.
А в чем разница?