Nuestro sitio web utiliza ASP.NET MVC para una parte de las páginas del mismo. Estas URL generalmente tienen el formato http://oursite/detail.mvc/12345/pictures/. En esta URL, 12345 es una identificación en la base de datos. Tenemos varios cientos de miles de objetos para los cuales mostramos páginas de detalles. Recientemente notamos un aumento en el uso de memoria para el sitio, así que investigué un poco. Hicimos un volcado de memoria del sitio de producción y descubrimos que una cantidad significativa del uso total de la memoria era causada por cadenas en Caché de la forma "dmachine/webroot/1/site/detail.mvc/12345/pictures /" y "H : \ site \ detail.mvc \ 12345 \ pictures \ ".Evite que muchas URL de MVC diferentes llenen caché ASP.NET
La investigación adicional y el uso intensivo de Reflector han demostrado que estas cadenas se almacenan en ASP.NET Cache en forma de un objeto System.Web.CachedPathData. Esto es creado por ConfigurationManager cuando lee información del archivo web.config. Llama a HttpContext.GetSection() -> HttpContext.GetConfigurationPathData() -> CachedPathData.GetVirtualPathData(). Eventualmente, en CachedPathData.GetConfigPathData, la ruta virtual se determina para la ruta solicitada y esta se almacena en caché en ASP.NET Cache sin vencimiento.
Ahora el problema es que tenemos millones de URL diferentes, y para cada ruta, el sistema de configuración almacena una cantidad de cadenas (configPath, ruta virtual, ruta física) en la memoria caché. Con el tiempo, esta información consume varios cientos de MB, casi todos los datos en caché.
Supongo que cuando la memoria escasea, estas entradas se eliminarán, pero en las operaciones no confían en los procesos que crecen y crecen. También parece muy ineficiente. ¿Hay alguna manera de decirle al HttpContext que no guarde en caché esta información para cada URL única? ¿O quizás podamos asignar primero la ruta de solicitud a una URL más simple y usarla para seleccionar la web.config correcta?
La opción 2 parece bastante coja, ya que elimina una de las características más agradables y más visibles de la estructura de mvc de ASP.NET. En nuestro caso, no importaría ya que también tenemos un dll de reescritura de ISAPI en su lugar. Pero todavía parece una solución débil. –