2009-09-14 15 views
6

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?

risposta

1

Beh ho pensato sopra (Teun e lavoro presso la stessa azienda), e abbiamo due opzioni per quanto riguarda posso dire:

  1. non fare nulla. Questo articolo contiene un commento di un ragazzo del team asp.net e mostra un paio di modi per impedire che la cache cresca e cresca: http://forums.asp.net/p/985551/3297967.aspx#3297967, ma non risolve il problema di scrivere una voce cache per ogni possibile percorso, ma garantisce che la cache non genererà alcuna eccezione di memoria insufficiente.

  2. Risolvere il problema con una soluzione alternativa, utilizzare i parametri di querystring anziché i percorsi fissi (/controller.mvc?action=X & parametri = Y invece di controller.mvc/action/params). In questo modo solo controller.mvc viene memorizzato nella cache.

Dopo tutto, non penso che questo sia davvero un problema.

+2

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. –

Problemi correlati