2008-11-30 16 views
6

Ejecutamos un sitio de contenido de volumen relativamente alto. Al igual que la mayoría de los sitios de contenido, la mayoría de cada página es relativamente estática. Los artículos rara vez cambian, lo que los convierte en buenos candidatos para alguna forma de almacenamiento en caché estático/borde. Sin embargo, hay dos grandes problemas. Los elementos secundarios de la página (navegación, listas de contenido reciente, etc.) cambian con bastante frecuencia, invalidando rápidamente las páginas "completas" almacenadas en caché. También es bastante común que incluyamos más bits dinámicos en una página, como información específica del usuario, etc.¿Procesamiento posterior de solicitudes HTTP con proxy inverso? (como el ESI de Akamai)

Sería realmente bueno tener un proxy inverso/equilibrador de carga que el contenido posprocesado y nos permita manejar incluya en el proxy/borde. La solicitud inicial al backend devolvería una plantilla aproximada, luego el software proxy podría procesar esa plantilla para completarla. El margen de beneficio podría ser algo como esto:

<html> 
<body> 
    <div id="content"> 
    Lorem ipsum whackem smackem. 
    <% 
     dynamic "http://related.content.service/this/story" 
    %> 
    </div> 
    <div id="sidebar"> 
    <% 
     dynamic do |request| 
     url = "http://my.user.service/user-widget.html" 
     if request.cookies.contains?("user_token") 
      url = "http://my.user.service/" + request.cookies["user_token"] + "/user-widget.html" 
     end 

     error_text = "User service not available" 
     { :url => url, :timeout => 500, :error => error_text } 
     end 
    %> 
    </div> 
</body> 
</html> 

Lo que verá en ese ejemplo es un pequeño fragmento de Ruby que determina el archivo incluido en base a un valor de cookie, a continuación, devuelve un hash con la URL para tirar en , un tiempo de espera y algo de texto predeterminado para mostrar en caso de error. En teoría, todas las inclusiones podrían solicitarse de forma asíncrona también.

Según tengo entendido, Amazon hace algo como esto. Los servicios de back-end generan varios componentes de página, con límites estrictos de tiempo de espera para garantizar la velocidad general de la página. Esperaba que su servicio CDN incluyera algo como esto, ¡pero no es así!

Hay una especificación W3 para Edge Side Includes (ESI) es casi lo que quiero. Sin embargo, hay muy poco apoyo para eso. Está disponible a través de Akamai, hay algún software de Oracle que lo hace, y el caché de Varnish de código abierto tiene una implementación muy básica. También es un formato XML realmente feo.

Entonces la pregunta es: ¿qué me dejará hacer lo que quiero? ¿Alguien más está haciendo las cosas de esta manera?

Respuesta

2

configure Nginx como interfaz y use SSI para seleccionar las partes dinámicas de las páginas. La fuente dinámica puede ser un servidor HTTP, como Apache, o un servidor FastCGI, por ejemplo, PHP o Django.

edición:

Muchos servidores web soportan algún tipo de SSI (Server Side), esta característica le permite añadir algunas etiquetas en el código HTML como una forma muy limitada de secuencias de comandos, mucho más simple y más rápido (o más) de PHP. Al usar esto, puede establecer páginas estáticas con la mayor parte del contenido, y para las 'pequeñas partes dinámicas', una etiqueta SSI hace referencia a una página dinámica generada en otro lugar.

Me gusta especialmente nginx como interfaz para casi cualquier cosa. es muy rápido, ligero en recursos y enormemente escalable (piense en un código más limpio y estable). el autor lo describe no como un servidor web de propósito general; pero como una interfaz de proxy. Los backends pueden ser un servidor HTTP (generalmente Apache) o procesos FastCGI (PHP, Python, Perl, lo que sea), o una granja de cualquiera de los dos, o ambos.

el módulo memcached es increíble, usa memcached (que es la tabla hash distribuida de uso general más rápida y escalable) para relacionar directamente una página web con una URL, sin acceso al disco. dado que a memcached se puede acceder desde "fuera" del servidor web, se puede usar incluso con páginas dinámicas (con una URL sana/asignación de recursos); pero no creo que ayude mucho en tu caso. en cualquier caso, primero haga que funcione con SSI, luego puede (si es necesario) optimizar la parte dinámica con memcached.

+0

¿Puede ampliar esta respuesta en absoluto? No parece que me da mucho de lo que quiero, pero es posible que me esté perdiendo algo. – MrKurt

+0

Ah, eso es un poco más útil. Sin embargo, realmente no me ayudaría a incluir las cosas condicionalmente, lo que lo hace menos útil para los tipos de escenarios en los que estoy interesado. – MrKurt

+0

recuerde que las 'cosas' que SSI puede insertar en toda la página pueden generarse dinámicamente por cualquier servidor back-end. – Javier

1

Sé que algunas personas han escrito sobre el uso de nginx SSI con el módulo Memcache nginx para unir fragmentos de contenido. Es mucho más limitado que algo como ESI, pero sigue siendo útil.

2

Por lo tanto, resulta que Varnish tiene (y tuvo) soporte básico de ESI que hace casi todo lo que yo quería. Si alguien necesita hacer algo de ESI, Varnish parece funcionar bastante bien para eso. Es bastante básico, pero aún impresionante.

1

Akamai tiene una solución para Edge Computing que permite que J2EE se ejecute en el Edge. Otras alternativas hoy incluyen cualquier servicio de Cloud Computing: Rackspace y Amazon son un par de jugadores en este mercado. Lo ideal sería utilizar una combinación de CDN y Cloud Computing para obtener el resultado deseado. Además, puede optar por que el contenido dinámico se sirva de manera asincrónica a través de un servicio web después de que se cargue la plantilla de página y luego simplemente almacenar en caché el contenido de la página estática con la plantilla html.

Cuestiones relacionadas