С чего начинается Performance Testing
#21
Отправлено 15 марта 2005 - 16:25
Ассептор:
Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages). Произвести объемное тестирование именно входной точки вашей системы, сравнить потом результаты с результатами объемного тестирования системы т.е. может оказаться, что ваша система, представляющая собой мощный кластер, в состоянии поддерживать одновременную работу, к примеру, ста тысяч пользователей, а fix-сообщения могут обрабатываться, к примеру, только от десяти тысяч.
Initiator:
Сделать то же самое, только в противоположном направлении.
Для тестирования вас как инициатора можно использовать стандартный ui или сразу фасады вашей системы, потому как они уже умеют передаваться в fix-формат.
Для тестирования системы как аксептора, для имитации неправильного поведения\сбоев инициатора, я пишу свой код. Для проверки стандартных операций использую quickfix (http://www.quickfixengine.org/)
#22
Отправлено 15 марта 2005 - 16:59
Спасибо, но не могли бы вы прояснить для меня ещё пару вопросов :) ?
Для тестируемой мной системы ето несколько не актульно, т.к. распределение происходит на этапе логона (не большой объем данных) в связи с чем, наверное, пропадает смысл тестировать ?Кроме 'response time и объема пользователей при котором один из 10-15 серваков сдохнет' хорошо бы протестировать систему распределения нагрузки, т.е. не только объемно (найти время, когда 'один из серваков сдохнет'), но и функционально (например, все ноды сразу не будут пытаться обрабатывать входящие fix-messages).
Произвести объемное тестирование именно входной точки вашей системы, сравнить потом результаты с результатами объемного тестирования системы т.е. может оказаться, что ваша система, представляющая собой мощный кластер, в состоянии поддерживать одновременную работу, к примеру, ста тысяч пользователей, а fix-сообщения могут обрабатываться, к примеру, только от десяти тысяч.
имеется ввиду поток данных к "клиенту" ?Initiator:
Сделать то же самое, только в противоположном направлении.
Peter Levin
#23
Отправлено 16 марта 2005 - 06:32
На входную точку приходит LogonRequest, после этого все опреации производит определенный нод? Как эта система будет работать в случае нагрузки? Т.е. у вас есть, например, четыре нода, одна точка входа. Приходит новый LogonRequest, на одном ноде обрабатывается, например, двадцать тысяч пользователей, на двух других по десять тысяч, а на последнем одна. Хочется, чтобы обработка ушла именно к тому ноду, который наименее загружен. Т.е. проверить систему распределения нагрузки, реализованную в аксепторе.Для тестируемой мной системы ето несколько не актульно, т.к. распределение происходит на этапе логона (не большой объем данных) в связи с чем, наверное, пропадает смысл тестировать ?
Да, допустим, вы заявляете, что ваша система интегрирована с другой по fix'у, причем поддерживается одновременная работа тридцати тысяч пользователей. Вы знаете, что сама ваша система справляется с такой нагрузкой, но не факт, что initiator пропустит через себя такой объем. Т.е. найти максимум для инициатора, сравнить с максимумом самой систему и заявленным максимумом.имеется ввиду поток данных к "клиенту" ?
#24
Отправлено 16 марта 2005 - 07:03
responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением.
Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.
#25
Отправлено 16 марта 2005 - 12:21
А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..
#26
Отправлено 16 марта 2005 - 15:54
Response time важен для любых клиент/серверных систем, не только web. Хотя из данного топика у меня не сложилось впечатление, что речь идет о web приложении.responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением.
#27
Отправлено 16 марта 2005 - 15:58
Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.А как, если не нагрузочным тестированием, можно проверить что, например, при ста пользователях запросы вообще перестают обрабатываться? Здесь речь уже идет не о response time..
#28
Отправлено 16 марта 2005 - 16:33
Response time важен для любых клиент/серверных систем, не только web.
Полностью с вами согласен. Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.Если запросы перестают обрабатываться, то клиент, как правило, не получает ответов от сервера. Соответственно response time увеличивается вплоть до time out.
Peter Levin
#29
Отправлено 16 марта 2005 - 17:33
...работает с арендованными линиями, кадровой трансляцией (frame relay), Интернетом, и т. д. Не определяет конкретный тип протокола безопасности.
Так это протокол транспортного уровня что ли? Я имел в виду application level protocol. Как вы собираетесь инструмент подбирать?[/quote]
Sorry for delayed reply :)
Тул у нас есть свой (в смысле наши девелоперы написали), заточенный конкретно под клиентскую систему, задача состоит в том чтоб дописать его так чтоб он Performance Testing осуществлять мог, а нашему отделу как раз поручили, кроме остальных performance related issues :) , сформулировать список requirment'ов к этому тулу, как раз в связи с этим и возникает проблема замеряемых метрик, все которые есть в LR сетапить нет смысла, вот и мучаюсь сейчас думая что может пригодиться что нет.
Peter Levin
#30
Отправлено 17 марта 2005 - 03:08
По response time, естественно, причину проблемы определить невозможно. Response time - это всего лишь температура больного. Чтобы понять причину высокой температуры нужны приборы разной степени сложности. Tот же LoadRunner, например, такие "приборы" обеспечивает.Но, как я счиатаю, задача Performance Testing'а, не только выявить наличие проблемы, но и выяснить на каком она уровне происходит, то ли это дефект кода, то ли hardware, то ли ещё чего :), а по одному response time это сделать достаточно проблематично.
#31
Отправлено 17 марта 2005 - 08:40
Неверно по нескольким пунктам.responce time - это один из немногих показателей, с которым сталкиваются пользователи при работе с веб-приложением. Собственно, цель нагрузочного тестирования (для веб приложения) в том и состоит, чтобы уменьшить время отклика.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой". Как правило, в десятки - сотни (редко в тысячи) раз больше показателя "Сколько пользователей в секунду обслуживает сервер"
3) Пользователь, как правило, наблюдает не время отклика сервера, а время отклика системы в целом.
Пример.
Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.
Что вы имеете в виду под временем отклика, время до получения первого байта или до получения последнего? Второй показатель более важен.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#32
Отправлено 17 марта 2005 - 11:44
Определение критериев загрузки по Microsoft:Не подскажете ли что можно придумать для нагрузочного тестирования этой системы, кроме:
1.Response time
2.Объема пользователей прикотором один из 10-15 серваков сдохнет
И что использовать для тестирования выше перечисленного ?
- большое количество ошибок в системном журнале событий или журналах веб-сервера.
- установить порог использования процессора
- установить порог использования памяти.
- установить порог отклика на запрос страницы
- достичь рассчитанного на основании бизнес правил числа запросов в секунду или
количества параллельных сессий.
- довести нагрузку до точки, в которой пропускная способность упадет очень сильно.
А насчет инструментария - это зависит от тестируемого приложения, Ваших предпочтений, и количества денег, которые Вы готовы выложить за инструмент:)
Я предпочитаю Load Runner. Можно использовать также Silk Performer, Application Center Test от Microsoft, Rational и. т. д.
#33
Отправлено 17 марта 2005 - 12:15
1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.
2) Сколько пользователей может работать в системе - этот показатель вообще-то должен указываться в документации, а не рассчитываться исходя из результатов тестирования. И если Ваш продукт рассчитан на конечного пользователя - то ему, пользователю, до лампочки, сколько одновременных коннектов выдерживает система. Он имеет дело именно с временем отклика приложения.
#34
Отправлено 17 марта 2005 - 12:23
Я говорил о времени отклика приложения, а не сервера.Вася, работающий на P-166 по диалапу, запросил из библиотеки Машкова документ, объемом 30к.
Сервер отдал все за 0.1 сек; качалось по сети - 8 сек; форматировалось на клиенте - 7 сек
Итог: responce time сервера - 0.1 сек, пользователь имеет дело с задержкой в 15 сек.
Что вы имеете в виду под временем отклика, время до получения первого байта или до получения последнего? Второй показатель более важен.
Время отклика приложения (речь идет о веб приложении) включает в себя:
- Задержки на веб-уровне.
- Задержки в базе данных
- Сетевые задержки.
#35
Отправлено 17 марта 2005 - 12:43
1) Оригинальные у вас суждения о тестировании :) Как уже написал SALar, тестирование ничего не меняет, оно нужно для анализа полученной в ходе разработки системы.1) Если тестирование ничего не меняет, то зачем же оно вообще Вам нужно?Неверно по нескольким пунктам.
1) Тестирование само по себе ничего изменить не может, или это уже не тестрование. Цель нагрузочного тестирования - получение некоторых показателей.
2) Время отклика - важный показатель, но не самый важный. Более того, очень часто его в отчете вообще не указывают. Самый важный показатель "Сколько пользователей может работать одновременно с системой"
Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя. Именно поэтому рекомендуется начинать тестирование как можно раньше.
2) Сколько пользователей может работать в системе - этот показатель вообще-то должен указываться в документации, а не рассчитываться исходя из результатов тестирования. И если Ваш продукт рассчитан на конечного пользователя - то ему, пользователю, до лампочки, сколько одновременных коннектов выдерживает система. Он имеет дело именно с временем отклика приложения.
2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)
#36
Отправлено 17 марта 2005 - 12:59
,Mar 17 2005, 02:43 PM] 1) Оригинальные у вас суждения о тестировании :) Как уже написал SALar, тестирование ничего не меняет, оно нужно для анализа полученной в ходе разработки системы.
2) В максимальное количество пользователей вписываете в документацию как душа возжелает? ;)
Ох, если бы это были мои суждения - я бы уже был богаче Билла Гейтса.
Уменьшение responce time является главной целью нагрузочного тестирования - это утверждает Microsoft, и в этом случае я с ними совершенно согласен.
Но я никому не навязываю это мнение, упаси Боже! Нравится "анализировать полученную в ходе разработки систему" - пожалуйста! Успехов в Вашем многотрудном начинании:)
2) Максимальное количество пользователей расчитывается на стадии проектирования проекта, - по крайней мере, у нас.
Ну знаете, есть бизнес правила, маркетинговые исследования, прогнозы аналитиков. Цифра эта, конечно, не константа, и может меняться за время жизни приложения.
А как Вы расчитываете ? По типу " я его слепила из того, что было, а потом что было, то и полюбила"?
#37
Отправлено 17 марта 2005 - 13:04
Гм, а если при некотором количестве одновременных пользователей система начинает глючить или вообще падать, а время отклика остаётся на нормальном уровне...И если Ваш продукт рассчитан на конечного пользователя - то ему, пользователю, до лампочки, сколько одновременных коннектов выдерживает система. Он имеет дело именно с временем отклика приложения.
2 Pet[EG]
Да, но с учётом этого анализа будут фиксится баги, выпускаться новые релизы, итп. Следовательно - меняет.Оригинальные у вас суждения о тестировании Как уже написал SALar, тестирование ничего не меняет, оно нужно для анализа полученной в ходе разработки системы.
Peter Levin
#38
Отправлено 17 марта 2005 - 13:09
Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)Насколько я знаю, тестирование меняет многое - иногда даже саму архитектуру проекта - если выясняется, что добиться
требуемых параметров другими способами нельзя.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#39
Отправлено 17 марта 2005 - 13:12
Как уже говорил Дмитрий - если система упала - значит responce time плавно перешел в time out:)Гм, а если при некотором количестве одновременных пользователей система начинает глючить или вообще падать, а время отклика остаётся на нормальном уровне...
как может остаться время отклика прежним, если система упала? :)
Но вообще то я говорил о главной цели нагрузочного тестирования. Конечно, есть еще и другие:)
#40
Отправлено 17 марта 2005 - 13:17
Блин, ну почему на этом форуме масса людей, любящих повыпендриваться?Слушайте, а ведь Меркури наверное и не догадывается, что ЛоадРаннер -- это инструмент для изменения архитектуры системы :)
Предполагаю, что от малых знаний и больших амбиций.
Что тут сказать... как говорил герой классической комедии: "А Вы не знаете, так молчите"
:)
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных