Я тоже уже разные попробовал:

Visual Studio Profiler

CLR Profiler for .NET Framework 4

CLR Profiler for .NET Framework 4.5

ANTS Memory Profiler 8 от RedGate

dotMemory от JetBrains

.NET Memory Profiling от SciTech

Когда в ANTS Memory Profiler я начинаю сессию через Attach to process и пытаюсь взять Shapshot, то получаю исключение и w3wp процесс естественно убивается

dotMemory от JetBrains и .NET Memory Profiling от SciTech без проблем цепляются к w3wp процессу и снимают Shapshot-ы.
В последнем правда функция "Show real time data" не работает, приходится Snapshot-ы наугад снимать.

Чуть позже расскажу, что я вообще делаю, чтобы было понятно, зачем я вообще всем этим интересуюсь

Denis.А я юзаю велосипед и не парюсь:) постшарп+самописный логер+azure table storageИ как Вы используете свой велосипед? Что логируете-то? Всё подряд? :)

Denis.Из профайлеров мне нравится больше всего антс.Мне пока dotMemory от JetBrains. Минимум необходимых настроек и работает без глюков, и не тормозит.

НахлобучНаписали аналог StatsD/CollectD/Graphite на .NET. Готовим код к публикации под открытой лицензией.

Умет отслеживать практически любые метрики приложений в реальном времениЭто как? Само что-ли в код встраивается? Нахлобучвыполнять аналитические преобразования (например, можно запросто получить медианное время выполнения запросов к БД, агрегированное число регистраций на сайте в блоках по 15 минут, интегралы-производные)А вот это интересно. Я бы конечно R ради этого не против прикрутить, но на это же надо время и настроение

НахлобучskyANAЭто как? Само что-ли в код встраивается? Не так круто, конечно. Нужно в ключевых местах расставить вызовы вида xxx.Increment("signup"); xxx.Gauge("cpu_usage") и т.д. Данные передаются по UDP на агрегирующий сервер.А есть возможность не просто увеличивать счётчики и замерять значение показателя, а только если превышен некий threshold? Ну чтобы не засирать сервер.

НахлобучskyANAА есть возможность не просто увеличивать счётчики и замерять значение показателя, а только если превышен некий threshold? Ну чтобы не засирать сервер.В этом нет смысла по нескольким причинам. "Засрать" что-то проблематично из-за специфики работы -- если для какой-то метрики отправлен хотя бы один сэмпл, то БД под её (метрики) хранение инициализируется целиком. Потом, если ограничиваться только пороговым значением, то может потеряться полезная информация. Ну и само пороговое значение интереснее выводить в виде горизонтальной линии на графике и опосля с ней играться.Извините, но есть-ли в этом смысл мы решим сами в нашей конкретной ситуации. Достаточно было сказать нет.

EDUARD SAPOTSKIРешили дополнить тему вопросом тестирования WCF - сервисов захощенных на IIS.
Кто как решает подобные задачи? Спасибо.Если речь о нагрузочном тестировании, то у нас это происходит так.

Тестировщики разрабатывают набор сценариев. Для каждого из них записывается (record) или пишется ручками тест в Visual Studio.
На базе реализованных таким образом сценариев в студии замешивается (mix) нагрузочный тест.
Указывается количество пользователей (для начала 5), продолжительность нагрузки, различные каунтеры (характеристики производительности) на клиентской машине.

Сервер, где развёрнут WCF сервис, выводится из фермы и все запросы, что генерирует нагрузочный тест, идут на него (в hosts прописывается).

Далее определяемся с характеристиками производительности, что хотим отслеживать на целевом сервере, составляем из них User Defined Set в Performace Monitor (встроен в Windows, perfmon.exe).
Set можно сохранить в виде XML, дать админам, чтобы они распространили его на все сервера фермы. И на тестовые сервера.

Запускаем на клиентской машине нагрузочный тест, на сервере Performance Monitor. Получаем результаты, сохраняем. Увеличиваем количество пользователей на 5-10, снова запускаем тест и т.д.

На основе полученных со всех тестов результатов составляем отчёт, где удобно смотреть зависимость характеристик производительности. Делаем выводы, что-то меняем в инфраструктуре, что-то в конфигурации сервера, что-то в коде.

И по кругу. Пока значения показателей не будут нас удовлетворять.

Когда выходит новая версия продукта, то тестировщики повторяют процедуру. Если характеристики производительности не ухудшились, то просто составляют отчёт и сохраняют для истории.

Если набор счёчиков производительности, встроенных в Windows и доступных в Performance Monitor не устраивает, то можно добавить своих счётчиков при помощи класса System.Diagnostics.PerformanceCounterCategory.
И писать в них при помощи класса System.Diagnostics.PerformanceCounter (читать кстати тоже можно, так что не обязательно пользоваться Performance Monitor).

Если не хватает счётчиков производительности, то есть механизм трассировки событий для Windows (Event Tracing for Windows, ETW).

EDUARD SAPOTSKI, студия позволяет замерить отклик и запустить сценарий в несколько потоков, зачем это делать на коленке?

Также IIS в режиме autoConfig="true" может выставить ограничение в 12 рабочих потоков на ядро, запросы начнут вставать в очередь (показатель Request Queued), а ты будешь искать проблему в SQL Server-е.

EDUARD SAPOTSKIЕсли увижу что идет 12 потоков на ядро, я буду искать другой сервер или собирать ферму!Не в сервере дело может быть. Я же пишу: "IIS в режиме autoConfig="true" может...".

Вообщем это для справки, чтобы ты вдруг ферму не начал собирать

А что касается функциональных тестов, то их у нас полностью пишут тестировщики в Visual Studio под Selenium WebDriver.
Запускаются они перед каждым push-ем в репозиторий в Gallio Icarus.

Перед моим отпуском начали внедрять SpecFlow и ещё какие-то тулзы пробовать, но я не помню их название :)