Прекрастный tool. Используем около года базовую (бесплатную) версию. Проблем особо небыло. Один раз в самом NewRelic была проблема с производительностью. Их профайлер убивал CPU. Нашли проблему все тем — же Debug Diagnostics Tool. Зарепортили багу, обновились и все работает в обычном режиме.
А вообще самое сложное — научиться понимать/читать иформацию NewRelic.
в умбрако в качестве кэша используется XML файл (XmlDocument). Cтроится дерево сайта из базы и сохраняется в файл. Следовательно когда нам нужет обьект Node или DynamicNode, новый инстанс создается и наполняется данными из XML файла.
Отсюда и memory pressure. Тоесть аналогично еслибы это были датасеты из базы, но в нашем случае это XML
задача стояла не спрятать проблему, а пофиксить проблему. Да можно было попробовать переключиться на 4.5, но это потребовало бы большего времени на тестирование всей системы. И где гарантии, что при background GC сайт выдердит желаемую нагрузку (при наличии описанной проблемы)? Да и кстати background GC только перестал бы блокировать другие потоки, при этом утилизация CPU была бы максимальной.
А вообще самое сложное — научиться понимать/читать иформацию NewRelic.
Отсюда и memory pressure. Тоесть аналогично еслибы это были датасеты из базы, но в нашем случае это XML
Мои поиски привели меня на статью — http://blogs.msdn.com/b/tess/archive/2006/06/22/asp-net-case-study-high-cpu-in-gc-large-objects-and-high-allocation-rates.aspx и благодоря ей я открыл для себя то что GC тоже может быть источником проблемы.
Тоесть эта статья стала отправной точкой.
По этой же причине и решил назвать статью более приближенным к проблеме названием.
Umbraco использует кэш для этого, следовательно никаких лишних запросов в базу.