Il nostro sito Web utilizza ASP.NET MVC per una parte delle pagine in esso contenute. Questi URL hanno in genere il modulo http://oursite/detail.mvc/12345/pictures/ In questo URL, il 12345 è un ID nel database. Abbiamo diverse centinaia di migliaia di oggetti per i quali mostriamo le pagine di dettaglio. Recentemente abbiamo notato un aumento dell'uso della memoria per il sito, quindi ho studiato un po '. Abbiamo creato un dump di memoria del sito di produzione e abbiamo scoperto che una quantità significativa dell'uso di memoria totale era causata da stringhe nella cache del formato "dmachine/webroot/1/site/detail.mvc/12345/pictures /" e "H". : \ sito \ detail.mvc \ 12345 \ immagini \".Impedire che URL MVC diversi riempiano ASP.NET Cache
Ulteriori indagini e l'uso intensivo di Reflector hanno mostrato che queste stringhe sono memorizzate nella cache di ASP.NET sotto forma di un oggetto System.Web.CachedPathData. Questo viene creato da ConfigurationManager quando legge le informazioni dal file web.config. Chiama HttpContext.GetSection() -> HttpContext.GetConfigurationPathData() -> CachedPathData.GetVirtualPathData(). Alla fine, in CachedPathData.GetConfigPathData, il percorso virtuale viene determinato per il percorso richiesto e questo viene memorizzato nella cache di ASP.NET senza scadenza.
Ora il problema è che abbiamo milioni di URL diversi, e per ogni percorso il sistema di configurazione memorizza un numero di stringhe (configPath, percorso virtuale, percorso fisico) nella cache. Nel tempo, queste informazioni consumano diverse centinaia di MB, tutti i dati nella cache.
Suppongo che quando la memoria scarseggia, queste voci verranno rimosse, ma nelle operazioni non si fidano dei processi che crescono e crescono. Sembra anche molto inefficiente. C'è un modo per dire a HttpContext di non memorizzare nella cache queste informazioni per ogni URL univoco? O forse possiamo prima mappare il percorso della richiesta ad un URL più semplice e avere quello usato per selezionare il web.config corretto?
L'opzione 2 sembra piuttosto zoppa, in quanto elimina una delle caratteristiche più belle e più visibili del framework mvc ASP.NET. Nel nostro caso, non importa come abbiamo una dll di riscrittura ISAPI in atto pure. Ma sembra ancora una soluzione zoppa. –