Pregunta

Estoy desarrollando un servicio web cuyos métodos se llamarán desde un "banner dinámico" que mostrará una especie de cola de mensajes leídos desde una tabla del servidor SQL.

El banner tendrá una fuerte presión en las páginas de inicio de sitios de alto tráfico;Cada vez que se cargue el banner, llamará a mi servicio web para obtener la nueva cola de mensajes.

Ahora:No quiero que todo este tráfico genere consultas a la base de datos cada vez que se carga el banner, así que estoy pensando en usar el caché de asp.net (es decir,HttpRuntime.Cache[cacheKey]) para limitar los accesos a la base de datos;Intentaré actualizar el caché aproximadamente cada minuto.

Obviamente intentaré tener la menor cantidad de mensajes posible, para limitar el tráfico.

Pero tal vez haya otras maneras de abordar tal escenario;por ejemplo, podría escribir la última versión de la cola en el sistema de archivos y hacer que el servicio web acceda a ese archivo;o algo que combine los dos enfoques...

La solución es el servicio web c#, asp.net 3.5, sql server 2000.

¿Alguna pista?¿Otros enfoques?

Gracias

andrea

¿Fue útil?

Solución

Depende de muchas cosas:

  • Si hay pocos cambios en los datos (piense en el backend con el botón "publicar" o lotes diarios), definitivamente usaría archivos estáticos (actualizados mediante push desde el backend).Usamos esta solución en un par de sitios grandes y funcionó muy bien.
  • Si los datos son lo suficientemente pequeños, el almacenamiento en caché de memoria (es decir,Http Cache) es viable, pero tenga cuidado con los problemas de bloqueo y también tenga en cuenta que Http Cache no lo hará funcionan muy bien bajo una gran carga de memoria, porque los elementos pueden caducar antes de tiempo si el marco necesita memoria.¡Me ha mordido antes!Con las advertencias anteriores, Http Cache funciona bastante bien.

Otros consejos

Creo que el almacenamiento en caché es un enfoque razonable y se puede ir un paso más allá y agregarle una dependencia SQL.

Almacenamiento en caché de ASP.NET:Dependencia de la caché de SQL con SQL Server 2000

Escribir un archivo es una mejor solución en mi humilde opinión: se sirve mediante el código del kernel IIS, sin la enorme sobrecarga de asp.net y puede copiar el archivo a CDN más tarde.

El cobro de dependencias que yo sepa no es muy eficiente con SQL Server 2000.

Además, una forma de evitar la limitación de memoria mencionada por Skliwz es que si utiliza este servicio fuera de la aplicación normal, puede aislarlo en su propio grupo de aplicaciones.He visto esto antes, lo que también ayuda.

Gracias a todos, como los datos son de tamaño pequeño, pero las tablas subyacentes cambiarán, creo que seguiré el camino de HttpCache:En realidad, necesito una forma de reducir el acceso a la base de datos, incluso si los datos están cambiando (esa es la razón para no usar una dependencia SQL directa como lo sugiere @Bloodhound).

Creo que haré algunas pruebas de estrés antes de hacerlo público.

Gracias de nuevo a todos.

Por supuesto, también podría (debería) utilizar las funciones de almacenamiento en caché en el Biblioteca SixPack .

  • Caché directo (normal), basado en HttpCache, que funciona colocando atributos en su clase.Es más sencillo de usar, pero en algunos casos hay que esperar a que el contenido se obtenga de la base de datos.
  • Recuperar caché previamente, desde cero, que, después de la primera llamada, comenzará a actualizar el caché detrás de escena y, en algunos casos, se garantiza que tendrá contenido sin esperar.

Más información sobre el Página de inicio de la biblioteca SixPack.Tenga en cuenta que el código (especialmente el caché de reenvío) se prueba con carga.

A continuación se muestra un ejemplo de almacenamiento en caché simple:

    [Cached]
    public class MyTime : ContextBoundObject
    {
            [CachedMethod(1)]
            public DateTime Get()
            {
                    Console.WriteLine("Get invoked.");
                    return DateTime.Now;
            }
    }
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top