С чего начинается Performance Testing

Хорошо, тогда, как кажется, задачу можно разделить: ваша система в роли инициатора и в роли аксептора. Также каждый из этих типов делится на, собственно, вашу систему и точку входа\выхода.
Ассептор:
Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages). Произвести объемное тестирование именно входной точки вашей системы, сравнить потом результаты с результатами объемного тестирования системы т.е. может оказаться, что ваша система, представляющая собой мощный кластер, в состоянии поддерживать одновременную работу, к примеру, ста тысяч пользователей, а fix-сообщения могут обрабатываться, к примеру, только от десяти тысяч.

Initiator:
Сделать то же самое, только в противоположном направлении.

Для тестирования вас как инициатора можно использовать стандартный ui или сразу фасады вашей системы, потому как они уже умеют передаваться в fix-формат.
Для тестирования системы как аксептора, для имитации неправильного поведения\сбоев инициатора, я пишу свой код. Для проверки стандартных операций использую quickfix (http://www.quickfixengine.org/)

2 bolshik
Спасибо, но не могли бы вы прояснить для меня ещё пару вопросов :) ?

Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages).

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

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

Initiator:
Сделать то же самое, только в противоположном направлении.

имеется ввиду поток данных к "клиенту" ?

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

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

имеется ввиду поток данных к "клиенту" ?

Да, допустим, вы заявляете, что ваша система интегрирована с другой по fix'у, причем поддерживается одновременная работа тридцати тысяч пользователей. Вы знаете, что сама ваша система справляется с такой нагрузкой, но не факт, что initiator пропустит через себя такой объем. Т.е. найти максимум для инициатора, сравнить с максимумом самой систему и заявленным максимумом.

А чем Вам не нравится responce time?
responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением.
Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.

[QUOTE]Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.[code=auto:0]
А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..

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

Response time важен для любых клиент/серверных систем, не только web. Хотя из данного топика у меня не сложилось впечатление, что речь идет о web приложении.

А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..

Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.

Response time важен для любых клиент/серверных систем, не только web. 

Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.

Полностью с вами согласен. Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.

[quote name='Dmitry_NJ' date='Mar 14 2005, 07:06 PM'][QUOTE (PeterL @ Mar 14 2005, 11:30 AM)
...работает с арендованными линиями, кадровой трансляцией (frame relay), Интернетом, и т. д. Не определяет конкретный тип протокола безопасности. 

Так это протокол транспортного уровня что ли? Я имел в виду application level protocol. Как вы собираетесь инструмент подбирать?[/quote]
Sorry for delayed reply :)
Тул у нас есть свой (в смысле наши девелоперы написали), заточенный конкретно под клиентскую систему, задача состоит в том чтоб дописать его так чтоб он Performance Testing осуществлять мог, а нашему отделу как раз поручили, кроме остальных performance related issues :) , сформулировать список requirment'ов к этому тулу, как раз в связи с этим и возникает проблема замеряемых метрик, все которые есть в LR сетапить нет смысла, вот и мучаюсь сейчас думая что может пригодиться что нет.

Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.

По response time, естественно, причину проблемы определить невозможно. Response time - это всего лишь температура больного. Чтобы понять причину высокой температуры нужны приборы разной степени сложности. Tот же LoadRunner, например, такие "приборы" обеспечивает.

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

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой". Как правило, в десятки - сотни (редко в тысячи) раз больше показателя "Сколько пользователей в секунду обслуживает сервер"
3) Пользователь, как правило, наблюдает не время отклика сервера, а время отклика системы в целом.
Пример.
Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.

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

Не подскажете ли что можно  придумать для нагрузочного тестирования этой системы,  кроме:
1.Response time
2.Объема пользователей прикотором один из 10-15 серваков сдохнет
И что использовать для тестирования выше перечисленного ?

Определение критериев загрузки по Microsoft:

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

А насчет инструментария - это зависит от тестируемого приложения, Ваших предпочтений, и количества денег, которые Вы готовы выложить за инструмент:)
Я предпочитаю Load Runner. Можно использовать также Silk Performer, Application Center Test от Microsoft, Rational и. т. д.

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"

1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.

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

Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.

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

Я говорил о времени отклика приложения, а не сервера.
Время отклика приложения (речь идет о веб приложении) включает в себя:
- Задержки на веб-уровне.
- Задержки в базе данных
- Сетевые задержки.

Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"

1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.

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

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

2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)

,Mar 17 2005, 02:43 PM] 1) Оригинальные у вас суждения о тестировании :) Как уже написал SALar, тестирование ничего не меняет, оно нужно для анализа полученной в ходе разработки системы.

2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)

Ох, если бы это были мои суждения - я бы уже был богаче Билла Гейтса.
Уменьшение responce time является главной целью нагрузочного тестирования - это утверждает Microsoft, и в этом случае я с ними совершенно согласен.
Но я никому не навязываю это мнение, упаси Боже! Нравится "анализировать полученную в ходе разработки систему" - пожалуйста! Успехов в Вашем многотрудном начинании:)

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

А как Вы расчитываете ? По типу " я его слепила из того, что было, а потом что было, то и полюбила"?

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

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

2 Pet[EG]

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

Да, но с учётом этого анализа будут фиксится баги, выпускаться новые релизы, итп. Следовательно - меняет.

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

Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)

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

Как уже говорил Дмитрий - если система упала - значит responce time плавно перешел в time out:)
как может остаться время отклика прежним, если система упала? :)
Но вообще то я говорил о главной цели нагрузочного тестирования. Конечно, есть еще и другие:)

Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)

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