Производительность.
Кто как измеряет/оценивает производительность своих приложений? Интересно сравнить, как это поставлено у разных людей. Мы обычно в критически важных случаях проводим нагрузочное тестирование, в остальных случаях производительность не тестируется и оптимизация осуществляется "на глазок" по критерию субъективной приемлемости. Ещё рулит что-то вроде статической проверки, когда явно ресурсоёмкие операции по возможности сокращаются. Как это делается у вас?
Если тест "на глазок" показывает неприемлемые задержки в выполнении - профайлер в руки (использую продукт от JetBrains) и вперед, искать узкие участки.
Серверный код и прочие места где производительность далеко не последний показаетель прохоядт через это обязательно. Плюс данные анализа покрытия кода..
PS: Методы отладки по производительности и проведения тестов (дымовых, на производительность и проч.) неплохо описаны в книге Джона Роббинса "Отладка приложений .NET и Microsoft Windows" из серии фундаментальные знания. Рекомендую :)
Занятно. Профайлер мы не юзаем, но, с другой стороны, серверный код тоже пишется редко. Вероятно, мой проект первым создал нагрузку на SQL Server 2005 нагрузку порядка 20 обращений к ХП с селектом по неиндексированному признаку, при этом, понятно, даже один такой поток нагружает процессор на 35%, остальные 65% приходятся на SQL Server. Однако и это - нештатная ситуация. А вот коллега проводил нагрузочное тестирование какого-то модуля, связаного с MS SQL Server, MSMQ, записью в лог и сетью, плюс там около сотни потоков. К его проекту грозятся подключить и меня, так что любопытствую заранее.
Цитата: Sanila_san
... MS SQL Server, MSMQ, записью в лог и сетью, плюс там около сотни потоков...
Такое дело сложно отлаживать, и не всегда удается приаттачить профайлер, два варианта:
1) Внедрнение подробных трейсов (логирования) и последующий просмотр (анализ). Тут хорошо себя проявляет Log4Net от Apache
2) Если средств предоставляемых готовыми продуктами для профилирования не достаточно, то возможно придется обратиться к CLR Profiling API (примеры использования + описание + сэмплы на диске есть в книге, упомянутой выше). Хотя это изврат.. скорее всего придется искать выход на месте исходя из условий проекта.
Цитата: Ap0k
Хотя это изврат.. скорее всего придется искать выход на месте исходя из условий проекта.
Там поступили проще: начали отключать фишки по одной, и выяснили, что де-то тормозит СУБД, где-то очередь, а в каком-то случае правильно отказаться от журналирования. Подробностей не знаю, но принцип примерно такой.