Здравствуйте, Аноним, Вы писали:

Performance Counters ?
Если не достаточно существующих, можно добавлять свои.

Здравствуйте, adontz, Вы писали:

A>Я имел ввиду что это делается конфигурированием NLog, а не вручную. Кстати при записи в БД парсер писать уже не придётся, вытягивать информацию будете SQL запросами с агрегатами.

Для хранения всей этой ненужной мне информации в БД места на диске не требуется? Вставка в БД не требует лока, она уже стала дешевле просто записи в файл? о_О

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

Здравствуйте, adontz, Вы писали:

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

Извините, то что вы предлагаете — это не решение.

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

Добрый день!

Возникла такая задача. Есть приложение на ASP.NET, которое состоит из кучи .ashx хендлеров.
Нужно с какой-то стороны подойти к определению узких мест. Причем собрать эту информацию нужно в "боевых условиях".
То есть нужно каким-то образом собрать статистику типа: какике хендлеры вызывались и сколько раз, средняя длительность работы итп. Собрать эту статистику нужно за какой-то значимый период — час, сутки, неделя.
Пробовал использовать dotTrace, но запускаемое под ним приложение работает супер-медленно. Что, конечно неприемлемо для живой системы, используемой кучей пользователей.

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

Здравствуйте, Аноним, Вы писали:

Логи IIS?

Здравствуйте, adontz, Вы писали:

A>Логи IIS?

Это конечно да, но тут два момента:

1) Многие ashx-хендлеры обрабатывают неколько разных реквестов, их хочется мерять по отдельности. Логи ииса, насколько я понимаю, тут уже не помогут;
2) После того как будут найдены самые медленные хендлеры, хочется спуститься на уровень ниже и мерять более детально уже там.

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

void f()
{
    using (Profiler.MeasureBlock("BlockName1")
    {
        // Code block 1
    }

    using (Profiler.MeasureBlock("BlockName2")
    {
        // Code block 2
    }
}

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

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

Здравствуйте, Аноним, Вы писали:

log4net и NLog умеют правкой конфигурации включать журналирования для конкретных классов.

Здравствуйте, adontz, Вы писали:

A>log4net и NLog умеют правкой конфигурации включать журналирования для конкретных классов.

Спасибо, посмотрю. Хотя навскидку в документации не нашел этого. Можно более точный линк?

С другой стороны, просто лог на вход/выход из блока — это я могу и ручками написать. Но мне не нужна куча информации по каждому вызову. Мне нужна только статистика — кол-во вызовов, средняя продолжительность вызова и тому подобное. Т.е. если я буду логировать все, то:
1) логи получатся огромными и будут занимать дисковое пространство на сервере. Нужно будет сладить, чтобы место не закончилось и т.п.;
2) будут существенно влиять на производительность (каждая запись в лог-файл — это лок, насколько я понимаю);
3) нужно будет писать тулзу для парсинга и анализа логов, чтобы получить из них интересующую меня статистику.

В общем, наверное не подходит

Здравствуйте, Аноним, Вы писали:

NLog.LogManager.GetLogger(this.GetType());

и в конфигурации типы прописываются по именам.

А>1) логи получатся огромными и будут занимать дисковое пространство на сервере. Нужно будет сладить, чтобы место не закончилось и т.п.;

Можно писать в БД.

А>2) будут существенно влиять на производительность (каждая запись в лог-файл — это лок, насколько я понимаю);

Можно писать асинхронно.

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

Это да.

Здравствуйте, adontz, Вы писали:

A>Можно писать в БД.
A>Можно писать асинхронно.

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

Здравствуйте, Аноним, Вы писали:

A>>Можно писать в БД.
A>>Можно писать асинхронно.
А>Понятно, что можно делать все что угодно и добиться приемлемого оверхеда итп. Я просто наивно подумал, что не я первый кто столкнулся с такой задачей и существуют готовые решения.

Я имел ввиду что это делается конфигурированием NLog, а не вручную. Кстати при записи в БД парсер писать уже не придётся, вытягивать информацию будете SQL запросами с агрегатами.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>Performance Counters ?
А>Если не достаточно существующих, можно добавлять свои.

Да, я в общем их и юзаю сейчас. Но не нравится вот что:
1) Счетчики нужно устанавливать — нужно писать функцию-инсталлятор (и обновлять ее при каждом добавлении/удалении счетчика).
2) Много кода получается. Например, хочу счиать среднее время выполнения функции. Нужно создать два объекта счетчиков (сам счетчик + base счетчик), добавить код их диспоза тоже нужно не забыть. Затем, нужно померять время руками и обновить оба счетчика правильно. Довольно много шума в коде получается, не находите?

Возможно уже кто-то завернул все это в удобную для использования и непрожорливую библиотеку? Буду благодарен за линк.

Здравствуйте, Аноним, Вы писали:

А>Для хранения всей этой ненужной мне информации в БД места на диске не требуется?

На арендуемом веб-хостинге место под БД может тарифицироваться отдельно.

А>Вставка в БД не требует лока, она уже стала дешевле просто записи в файл? о_О

Я разве такое говорил?

А>Сорри, это все оверкилл и не годится для измерений на живой системе, уж очень велик оверхед. К тому же совершенно неоправданный — все то что будет писаться в базу, оно мне не нужно просто. Мне нужно простое саммари за какой-то период.

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

Здравствуйте, Аноним, Вы писали:

А>Добрый день!

А>Возникла такая задача. Есть приложение на ASP.NET, которое состоит из кучи .ashx хендлеров.
А>Нужно с какой-то стороны подойти к определению узких мест. Причем собрать эту информацию нужно в "боевых условиях".
А>То есть нужно каким-то образом собрать статистику типа: какике хендлеры вызывались и сколько раз, средняя длительность работы итп. Собрать эту статистику нужно за какой-то значимый период — час, сутки, неделя.
А>Пробовал использовать dotTrace, но запускаемое под ним приложение работает супер-медленно. Что, конечно неприемлемо для живой системы, используемой кучей пользователей.

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

А студийный профайлер или http://memprofiler.com или из этой стопки... http://habrahabr.ru/blogs/net/109418/...
В них четко видно реальную нагрузку на сервер со стороны каждого компонента...
Короче говоря имеешь дело с абсолютными величинами и четко видно что оптимизировать, можнт быть там один запрос который тормозит ну очень сильно но и запускается редко — оптимизация мало что даст, зато какойто мелкий очень часто вызывается и его хоть и малоеускорение может существенней разгрузить сервер...
А в логах видать ток количество вызовов, а что кто и кого тормозил, где ресурсы пошли нетуда, ничего не видно .
А собственное логирование, ток усугубит тормоза, а вот ясности там не так и много будет...
ПС логирование или (особенно)профайлинг могут в значительной степени снизить производительность системы.