Предел для хранения кеша HttpRuntime в мини-профилировщике mvc

Question

1. Я полагаю, что мини-профилировщик mvc хранит все времена отклика в кэше HttpRuntime.
   Пожалуйста, дайте мне знать, если я ошибаюсь, но если это так, то каков максимальный предел для этого кэша? Сколько операций можно профилировать до заполнения кеша? Мы используем мини-профилировщик для профилирования операций набора тестов, и набор тестов со временем будет расти, поэтому меня это беспокоит. Должен ли я быть обеспокоен?

2. На связанной ноте. Когда все тесты профилированы, я просто называю Save метод в SqlServerStorage класс мини профилировщика. И все времена ответа сохраняются в базе данных сервера SQL. Есть ли способ, которым я мог бы позвонить Save метод чаще, без запуска и остановки профилировщика снова и снова? Мы просто запускаем его в начале набора тестов и заканчиваем, когда все тесты профилированы. Мы рассматриваем одну запись в MiniProfilers таблица как один сеанс профилирования. Сейчас я не могу вызывать метод "Сохранить" более одного раза, потому что ему нужен новый MiniProfilerId каждый раз это называется.

Какие-либо предложения?

Answer 1

Я не знаком с мини-профилировщиком напрямую, но у меня достаточно опыта работы с кешем. Свойство HttpRuntime.Cache предоставляет ссылку на класс System.Web.Caching.Cache. Который является реализацией объектного кэша. В общем случае этот кеш является статическим, поэтому существует только один экземпляр. Вы можете настроить поведение этого кэша, используя файл Web.Config. Некоторые вещи, которые нужно иметь в виду в отношении кэша Windows, вы никогда не получите ошибку нехватки памяти, используя его. Кеш имеет процент от значения памяти, который говорит, насколько полным он должен быть заполнен. Как только он достигнет этого верхнего процента использования памяти, он начнет отбирать объекты из кэша, начиная с самых старых затронутых объектов. Таким образом, короткий ответ на ваш первый вопрос - нет, не беспокойтесь об ограничениях памяти, одна из главных особенностей управляемого языка - то, что вам никогда не придется беспокоиться о потреблении памяти, пусть инфраструктура справится с этим.

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

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