Как выделить проблему производительности для конкретного компонента инфраструктуры приложения? В частности, существуют ли отличительные маркеры в журналах результатов, которые различают узкие места на уровне веб-приложений, приложений и/или серверов баз данных?Как конкретно определить проблемы сервера из результата теста нагрузки (используя LoadRunner)?
Мне задали этот вопрос в интервью и пустили его в прошлое. Кажется, эта информация недоступна нигде.
В дополнение к SiteScope и другим безматричным мониторингам компонентов системы вам необходимо убедиться, что сценарий и сценарии работают должным образом. Это включает в себя правильную проверку ошибок и использование транзакций (и множество других вещей). Если транзакции достаточно подробные, это даст вам представление о по крайней мере запросах, имеющих проблемы с производительностью. После того, как у вас есть эти показатели, работайте с командой инфраструктуры, чтобы просмотреть журналы и другую информацию. Будучи итеративным процессом, можно провести тесты, чтобы сосредоточиться на меньшем и меньшем разделе инфраструктуры.
Кроме того, скрипты loadrunner не обязательно должны строго «проникать через входную дверь». Если у вас многоуровневая система, скрипты могут быть сделаны для непосредственного попадания в веб-серверы/приложения/базы данных.
Для поиска, сосредоточьтесь на любых измерениях, которые имеют тип поведения «колени» или «хоккейная клюшка». Вы можете подключаться к любым измерениям типа ресурса сервера непосредственно в контроллере и интегрировать статистику другой команды на этапе анализа. Сравните с эталонами на более низких уровнях виртуального пользователя, чтобы определить, что приемлемо и неприемлемо.
Удачи вам!
«Вы можете подключиться к любым измерениям типа ресурса сервера непосредственно в контроллере и интегрировать статистику других команд на этапе анализа» Я всегда хотел это сделать, но я никогда не уверен, что нужно запрашивать у сервера/сети/dba.Но в последнее время я начал составлять список KPI. Надеюсь, я скоро получу возможность использовать этот список или даже лучше, начните использовать SiteScope. – Bash
Этот тип информации обычно недоступен, просто просматривая стандартные результаты теста производительности.
Части информации, которую вы ищете, могут быть найдены с помощью SiteScope для мониторинга всех соответствующих серверов в тесте. SiteScope предлагает множество счетчиков, таких как CPU, Memory, Disk I/O и Network I/O - как видно на каждом сервере.
Эта информация, возможно, дает представление о том, где находится узкое место, и чем больше счетчиков вы добавляете на SiteScope, тем больше изменений, чтобы определить узкое место.
Это очень распространенное заблуждение, что узкие места в AppServer и DBServer можно было идентифицировать, просто просматривая время или обратные отклики, страницы и т. Д. (Веб-протокол), если, конечно, доступ к URI не определяет точный компонент (ы) в система ...
Это именно то, что я думал. Я уже сообщил интервьюеру, что мой опыт работы с сайтом-сайтом ограничен. Помимо этого, я не мог придумать ничего лучшего. Рад узнать, что я не просто теряю его. – Bash
Если учесть, что интервью сосредоточено на LoadRunner и SiteScope, я пришел к выводу, что он больше ориентирован на решения HP/Mercury. В этом случае я предлагаю вам изучить HP Diagnostics, и это интеграция LoadRunner возможностей.
Я думаю, что это отраслевое неверное представление о том, что инструменты находят решения или создают проблемы. Они этого не делают. Хороший тестер нагрузки может узнать больше, используя диспетчер задач Windows, чем идиот может узнать с помощью SiteScope или любого другого сверхмалого экстра-дорогого программного обеспечения. Возможно, интервьюеры хотели точно проверить это ... тогда прилипание к перечислению функций программного обеспечения будет большим минусом. – TheBlastOne
Я на 99% уверен, что этот вопрос был задан, чтобы узнать, придумали ли вы простые (вероятно, ложные или просто слишком простые) ответы или подробно изложите сложность темы в глубину. Нет ни одного KPI или измерения или процедуры, которые говорят вам «есть узкое место db». LR - это всего лишь инструмент, который позволяет точно определить виновника, разумно сужая производительность свиней, и этот интеллект не может быть формализован в простом ответе. – TheBlastOne