Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Производительность.

241
28 января 2008 года
Sanila_san
1.6K / / 07.06.2005
Кто как измеряет/оценивает производительность своих приложений? Интересно сравнить, как это поставлено у разных людей. Мы обычно в критически важных случаях проводим нагрузочное тестирование, в остальных случаях производительность не тестируется и оптимизация осуществляется "на глазок" по критерию субъективной приемлемости. Ещё рулит что-то вроде статической проверки, когда явно ресурсоёмкие операции по возможности сокращаются. Как это делается у вас?
713
29 января 2008 года
Ap0k
360 / / 13.03.2006
Особых отличий в том как это делает ваша команда у нас нет. Возможно только инструментарий..
Если тест "на глазок" показывает неприемлемые задержки в выполнении - профайлер в руки (использую продукт от JetBrains) и вперед, искать узкие участки.
Серверный код и прочие места где производительность далеко не последний показаетель прохоядт через это обязательно. Плюс данные анализа покрытия кода..
PS: Методы отладки по производительности и проведения тестов (дымовых, на производительность и проч.) неплохо описаны в книге Джона Роббинса "Отладка приложений .NET и Microsoft Windows" из серии фундаментальные знания. Рекомендую :)
241
30 января 2008 года
Sanila_san
1.6K / / 07.06.2005
Занятно. Профайлер мы не юзаем, но, с другой стороны, серверный код тоже пишется редко. Вероятно, мой проект первым создал нагрузку на SQL Server 2005 нагрузку порядка 20 обращений к ХП с селектом по неиндексированному признаку, при этом, понятно, даже один такой поток нагружает процессор на 35%, остальные 65% приходятся на SQL Server. Однако и это - нештатная ситуация. А вот коллега проводил нагрузочное тестирование какого-то модуля, связаного с MS SQL Server, MSMQ, записью в лог и сетью, плюс там около сотни потоков. К его проекту грозятся подключить и меня, так что любопытствую заранее.
713
30 января 2008 года
Ap0k
360 / / 13.03.2006
Цитата: Sanila_san
... MS SQL Server, MSMQ, записью в лог и сетью, плюс там около сотни потоков...


Такое дело сложно отлаживать, и не всегда удается приаттачить профайлер, два варианта:
1) Внедрнение подробных трейсов (логирования) и последующий просмотр (анализ). Тут хорошо себя проявляет Log4Net от Apache
2) Если средств предоставляемых готовыми продуктами для профилирования не достаточно, то возможно придется обратиться к CLR Profiling API (примеры использования + описание + сэмплы на диске есть в книге, упомянутой выше). Хотя это изврат.. скорее всего придется искать выход на месте исходя из условий проекта.

241
30 января 2008 года
Sanila_san
1.6K / / 07.06.2005
Цитата: Ap0k
Хотя это изврат.. скорее всего придется искать выход на месте исходя из условий проекта.

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

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог