2011-05-30 7 views
7

Estoy usando Symfony 2 para generar mis páginas a partir de datos en una base de datos MySQL. Para la mayoría de los contenidos, los usuarios deben ser autenticados, pero el contenido en sí mismo no cambia a menudo y no necesita ser personalizado para los usuarios. Entonces, ¿qué es una buena estrategia de almacenamiento en caché para evitar las llamadas a la base de datos mientras se mantiene el control de autenticación?Almacenamiento en caché agresivo del contenido generado mientras se mantiene la información de autenticación

+0

TFM parece tener cierta información decente - http://symfony.com/doc/current/book/http_cache.html - me parece que AppCache tiene todas las cosas que necesita, solo necesita comprobar si la solicitud fue autenticada , o a un recurso no público antes de almacenar en caché la respuesta. – smcphill

+2

Eso no resolverá su problema. Él busca cachear consultas para MySQL no solicitudes HTTP. –

Respuesta

0

He resuelto esto mediante el uso Zend_Cache interior las acciones almacenables para almacenar el resultado de la plantilla procesada. Luego creo un nuevo objeto Response a partir del contenido en caché. Si el caché está vacío, genero el contenido.

Pensé en crear un complemento que buscara una anotación y almacenara la salida de respuesta automáticamente, pero resultó que solo tengo 3-4 acciones de visualización que son almacenables y tienen reglas de creación de ID de caché muy complejas, así que puse el la lógica de almacenamiento en caché directamente en el código del controlador.

1

En pocas palabras, utilice Memcache para almacenar en caché el conjunto de resultados SQL durante un período de tiempo prolongado.

-1

Parece que tiene muchas opciones para almacenar en caché con symphony http://www.symfony-project.org/book/1_2/12-Caching (no para 2 pero creo que no ha cambiado mucho).

Se puede poner las sentencias SQL pesados ​​en su escritura, ya su vez en el almacenamiento en caché para ese guión

list: 
    enabled:  on 
    with_layout: false # Default value 
    lifetime: 86400 # Default value 

Además si está seguro de que la etiqueta generado no va a cambiar por un tiempo que podría utilizar Symfony dígale al navegador del usuario que ni siquiera moleste a su servidor por el contenido que hará que la página se cargue casi instantáneamente para el usuario.

$this->getResponse()->addCacheControlHttpHeader('max_age=1200'); // in seconds - less than 1 year seconds 

Sólo asegúrese de que su edad máxima es lo suficientemente pequeño que cuando algo cambia (por ejemplo una actualización de código) que el usuario no se quedó con la página de edad ya que no hay manera de obligarlos a solicitar que la página de nuevo corto de cambiar la url.

+0

Esto es para Symfony 1. – chiborg

0

Tal vez esto sea demasiado grande el cambio, pero el siguiente esquema puede ser útil en el caso:

crear varios conjuntos de páginas, una para aún no authed- usuarios (vamos a poner en la raíz del sitio) y otros para usuarios autenticados que deberían ver el mismo contenido (por ejemplo, dos o más deberían ver el mismo contenido cuando se autentican, luego crearemos un solo conjunto para todos ellos) y colocarlo en el directorio bajo la raíz Luego, cree archivos sencillos .htaccess/.htpasswd para cada uno de esos directorios 'for-authed-only' y luego será el problema del servidor web y no su script.

Espero que entiendas la idea. Es confuso decirlo, pero será fácil de implementar.

Ejemplo: supongamos que solo permite que los usuarios autenticados vean la página '/topsecret.html' en el sitio. Cree dir (/ authed), establezca HTTP-auth en él y coloque su topsecret.html en el directorio (para que sea '/authed/topsecret.html'). Ahora edite '/topsecret.html' y simplemente reemplace su contenido principal con el enlace 'lo siento, por favor autentíquese' que apuntará a '/authed/topsecret.html'.

0

Si usa Symfony2, está utilizando Doctrine2 si utiliza Doctrine2, el almacenamiento en caché debe estar habilitado de forma predeterminada.

Elija su controlador de caché para sus propósitos y no debería haber ningún problema. También podría interesarle específicamente el query result caching.

¡No use Doctrine sin metadatos y caché de consultas! Doctrine es altamente optimizado para trabajar con cachés. Las partes principales en Doctrine que están optimizadas para el almacenamiento en caché son la información de asignación de metadatos con la memoria caché de metadatos y las conversiones DQL a SQL con la caché de consulta .Estas 2 memorias caché requieren solo un mínimo absoluto de memoria, sin embargo, mejoran en gran medida el rendimiento en tiempo de ejecución de Doctrine. El controlador de caché recomendado para usar con Doctrine es APC. APC le proporciona con un código de operación-cache (que es muy recomendable de todos modos) y un almacenamiento de memoria caché muy rápido en memoria que se puede utilizar para los cachés de metadatos y consulta

Cuestiones relacionadas