Измерение производительности поставщика состояния сеанса ASP.NET SQL

У нас есть очень большое трехуровневое веб-приложение .NET 4.0 (ASP.NET, WCF, SQL Server 2008 R2) с некоторыми проблемами производительности, которые я пытаюсь диагностировать. Уровень ASP.NET использует поставщика состояний сеанса SQL, и существует достаточно широкое использование состояния сеанса.Измерение производительности поставщика состояния сеанса ASP.NET SQL

<sessionState mode="SQLServer" sqlConnectionString="..." cookieless="false" timeout="20"/>

Я пытаюсь выяснить, сколько времени требуется для загрузки и сохранения сеанса в базе данных. Обратите внимание, что это отличается от использования профайлера SQL или другого средства базы данных для измерения времени на этом уровне; Я хочу измерить общее время, затраченное на уровень ASP.NET. I.e. который будет включать сериализацию/десериализацию объектов сеанса, время соединения и время сохранения SQL/время загрузки.

Я довольно опытный разработчик (с начала 80-х годов), и у меня есть Google для часов сейчас - есть тонны статей, контрастирующих подходам к сеансу сеанса и общим концепциям производительности и т. Д., Но я ничего не могу найти на как реально измерить это общее время для поставщика состояния сеанса SQL. Первоначально я думал об использовании HttpModule для перехвата событий и использования секундомера, но, похоже, для этого нет чистого пути. (Я бы согласился на подход, который разумно с точностью до нескольких процентов ...)

Любые идеи и предложения очень ценятся, спасибо.

источник

2013-03-22 Keith Bluestone

ли вы пытаетесь добавить диагностический код с помощью 'Trace', а затем просто включить трассировку? Таким образом, вы можете очень тщательно диагностировать выбранные страницы. –

Куда вы добавили инструкции Trace? –

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

Могли бы вы не просто изменить тайм-аут сеанса на секунды, а затем на более низкую и меньшую величину, пока он не загрузит и не сохранит сеанс?

источник

2013-03-22 14:19:18 jakden

Спасибо за мысль ... Проблема в том, что состояние сеанса, как правило, собирается создавать, поскольку пользователи нажимают больше страниц, делают больше операций и т. Д. Будет важно фактически измерить производительность поставщика услуг в приложении, а не просто попадать в низкий порог тайм-аут. –

Управляемый стек может быть профилирован в профилировщике VS. См:

Для низкого материала уровня использования Xperf см Two Minute Drill: Introduction to XPerf

Для стороны SQL Server существует множество методик для устранения неполадок производительности, как Waits and Queues. Для конкретной продолжительности выписки/IO вы можете использовать трассировку профилировщика, см. Scenarios for Using SQL Server Profiler.

Теперь очень конкретного и инвазивной В вашем случае вы можете использовать счетчики производительности. Не тип запаса, но создайте свой собственный. См. Using XSLT to generate Performance Counters, чтобы облегчить установку сантехники, необходимую для увеличения вашего приложения с помощью собственных счетчиков перфомансов, а затем подключите свой код с отслеживанием производительности. Для захвата и анализа используйте стандартную цепочку инструментов счетчиков перфомансов (logman.exe, perfmon.exe).

источник

2013-03-22 16:09:43

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

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

Я бы развернул тест нагрузки на пустую страницу и позволил perfview работать в течение 30 секунд.

dottrace - простой профайлер, который также показывает количество процессорного времени, затраченного на звонок, я считаю.

источник

2013-03-22 16:14:43 usr

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

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

источник

2014-05-06 18:31:16

Измерение производительности поставщика состояния сеанса ASP.NET SQL

ответ

Смежные вопросы