Limit dla httpRuntime przechowywania cache w MVC mini profilera

Question

1. wierzę, że MVC mini Profiler przechowuje wszystkie czasy reakcji w httpRuntime pamięci podręcznej.
   Proszę dać mi znać, jeśli się mylę, ale jeśli tak, to jaki jest maksymalny limit dla tej pamięci podręcznej? Ile operacji może wykonać profil przed zapełnieniem pamięci podręcznej? Używamy mini profilera do profilowania operacji pakietu testowego, a zestaw testów będzie się powiększał w miarę upływu czasu, więc niepokoję się tym. Czy powinienem się martwić?

2. Na powiązanej notatce. Kiedy wszystkie testy zostały wyprofilowane, po prostu wywołuję metodę Save w klasie mini profilera. Wszystkie czasy odpowiedzi są zapisywane w bazie danych serwera SQL. Czy jest jakiś sposób, abym mógł się częściej odwoływać do metody Save, bez ponownego uruchamiania i zatrzymywania profilera? Po prostu uruchamiamy go na początku zestawu testowego i kończymy go, gdy wszystkie testy zostaną profilowane. Jeden wpis w tabeli MiniProfilers uznajemy za jedną sesję profilowania. Obecnie nie mogę wywołać metody "Zapisz" więcej niż jeden raz, ponieważ potrzebuje ona zawsze nowego MiniProfilerId za każdym razem, gdy jest wywoływana.

Wszelkie sugestie?

Answer 1

Nie jestem zaznajomiony z mini profilerem, ale mam spore doświadczenie z pamięcią podręczną. Właściwość HttpRuntime.Cache zapewnia odniesienie do klasy System.Web.Caching.Cache. Co jest implementacją pamięci podręcznej obiektów. Zasadniczo pamięć podręczna jest statyczna, więc istnieje tylko jedno wystąpienie. Możesz skonfigurować zachowanie tej pamięci podręcznej, używając pliku Web.Config. Niektórych rzeczy, o których należy pamiętać o pamięci podręcznej Windows, nigdy nie dostaniesz błędu pamięci za pomocą go. Pamięć podręczna ma procent wartości pamięci, która określa, jak powinien być pełny. Gdy zbliży się do tego maksymalnego procentu użycia pamięci, zacznie wycinać obiekty z pamięci podręcznej, zaczynając od najstarszych dotkniętych obiektów. Tak więc krótka odpowiedź na twoje pierwsze pytanie brzmi: nie, nie martw się o limity pamięci, jednym z głównych punktów sprzedaży zarządzanego języka jest to, że nigdy nie powinieneś martwić się o zużycie pamięci, pozwól ramie sobie z tym poradzić.

Jeśli chodzi o # 2, nie martwię się o to. Pamięć podręczna może odrzucić sam obiekt odpowiedzi, ale zaryzykowałbym przypuszczenie, że został już uwzględniony w wynikowej agregacji z profilera, więc naprawdę nie powinieneś potrzebować oryginalnego obiektu żądania, chyba że chcesz go dokładnie sprawdzić.

Krótko mówiąc, nie martwiłbym się tym, dopóki nie trafisz na prawdziwy problem. Niech pamięć podręczna spełnia swoją rolę i ufaj, że inżynierowie, którzy ją zbudowali, wiedzieli, co robią, dopóki nie uzyskasz dowodu w inny sposób.