Mejor práctica: cargar muchas cosas en la aplicación_start?

Question

Tengo una tienda en línea con muchos productos y otro contenido. Actualmente cargo todo el contenido en una lista global en Application_Start, que toma aproximadamente 15-25 segundos.

Esto hace que el sitio sea muy rápido, ya que puedo obtener cualquier producto/contenido en O (1) tiempo.

Sin embargo, ¿es esta la mejor práctica?

Actualmente tengo un webhotel que no es un servidor VPS/Dedicado, por lo que recicla la aplicación de vez en cuando, lo que da a los visitantes aleatorios tiempos de carga de hasta 15-25 segundos (solo para convertirse en un número mayor con más contenido). Esto, por supuesto, es totalmente inaceptable, pero supongo que se resolvería con un VPS.

¿Cuál es la forma normal de hacer esto? Supongo que una tienda web como Amazon probablemente no cargue todos sus productos en una lista enorme :-D

Cualquier idea o pensamiento sería muy apreciado.

Answer 1

Parece que ha respondido a su pregunta por su caso "Esto, por supuesto, es totalmente inaceptable".

Si su objetivo O (1) la solicitud normal a la base de datos para un solo producto es probable O (1) a menos que necesite tener combinaciones complicadas entre productos. Considera intentar descartar toda tu lógica de precaching y ver si tienes problemas con el rendimiento. Puede limitar el impacto de inicio mediante el almacenamiento en caché lento.

Los sitios grandes a menudo usan caché distribuido como MemcaheD.

Answer 2

Una configuración más escalable consiste en configurar un servicio web para proporcionar el contenido, que el sitio llama cuando lo necesita. El servicio web necesitará almacenar en caché el contenido que se necesita con frecuencia para lograr tiempos de respuesta rápidos.

Answer 3

La separación de responsabilidades lo ayudará a escalar para el futuro.

Con su configuración actual, usted está limitado a los recursos de su servidor web, y, como usted dijo, sus tiempos de arranque se descontrolarán a medida que continúe agregando más productos.

Si comparte la carga de cada solicitud de página con SQL Server, abre su aplicación para permitirle escalar según sea necesario. Con el tiempo, puede optar por agregar más servidores web, clúster SQL Server o cambiar a un nuevo back-end de la base de datos. Sin embargo, si toda la carga está en el grupo de aplicaciones, entonces usted se está limitando drásticamente.

Answer 4

En primer lugar, 15-20 segundos para cargar datos es demasiado tiempo, así que sospecho que estos casos

• Esta vez es para compilación y no la carga de datos
• Los datos son demasiado y se llena la memoria
• el método que se utiliza para leer los datos es muy lento
• el almacenamiento de datos es demasiado lento, o la estructura está en el archivo de texto y la lectura de la misma es lenta

Mi opinión es que almacena en caché solo una pequeña cantidad de datos que necesita usar muchas veces en poco tiempo. La forma en que la describes no es una buena práctica por algunas razones.

1. Si tiene muchas agrupaciones, lee los mismos datos en todas las agrupaciones y gasta memoria sin ningún motivo.
2. Los datos que almacena en caché no puede cambiarlos - es solo de lectura
3. Incluso si almacena algunos datos en caché, entonces necesita representar la página, y allí es donde realmente necesita hacer la caché, en el final render, no en datos.

Qué y cómo almacenar en caché.

• Almacenamos en caché la página final del renderizado.
• También configuramos el caché para la página y otros elementos para el cliente.
• Leemos y escribimos los datos de la base de datos tal como vienen y dejamos que la base de datos haga el caché, él sabe mejor.
• Si almacenamos en caché los datos, entonces deben ser pequeñas cantidades que deben usarse para bucle largo y evitamos la llamada a la base de datos muchas veces.

También almacenamos en caché cuando lo solicitan, y si no se utiliza durante mucho tiempo, o si la memoria necesita espacio, esta parte del caché ha desaparecido. Si alguna parte de los datos proviene de combinaciones complejas de muchas tablas, entonces hacemos una gran mesa plana temporal que mantiene todos los datos juntos, cada uno en una fila. Esta tabla es temporal y si necesitábamos demasiado, creamos un segundo archivo de base de datos temporal que conservamos esta parte de los datos.

¿Qué tan rápido se lee la base de datos? Bueno, es tan rápido que no necesita preocuparse por eso, necesita verificar otro punto de retrasos, como lo digo en el renderizado completo de una página, o algunas partes de la página.

Lo que debe preocuparse es un buen diseño de la base de datos, una forma buena y rápida de recuperar sus datos, y un buen código de optimización para mostrarlos.