SoftwareLibre.Net

Las dos entradas anteriores:

• Probando el mod_deflate de Apache
• Usando el mod_cache de Apache para que el mod_deflate no incremente la carga del servidor

trataban de conseguir optimizar el ancho de banda de nuestro servidor web comprimiendo el documento para que ocupara menos y de cómo lograr que el mismo contenido no se tenga que comprimir una y otra vez malgastando inútilmente ciclos de CPU. Sin embargo, aquella teoría estaba orientada a páginas estáticas… ¿Cómo podemos hacer lo mismo para contenido creado dinámicamente como es el generado por Wordpress? ¿Es aplicable? El contenido generado por Wordpress se puede enviar comprimido a través de varios mecanismos. Por un lado, podemos simplemente señalar la opción “WordPress debería comprimir las entradas (gzip) si los navegadores lo requieren” del panel de “Opciones de lectura” de Wordpress. Por otro, podemos habilitar la opción zlib.output_compression del php.ini (en /etc/php5/apache2/php.ini en Debian): ; Transparent output compression using the zlib library ; Valid values for this option are 'off', 'on', or a specific buffer size ; to be used for compression (default is 4KB) ; Note: Resulting chunk size may vary due to nature of compression. PHP ; outputs chunks that are few hundreds bytes each as a result of ; compression. If you prefer a larger chunk size for better ; performance, enable output_buffering in addition. ; Note: You need to use zlib.output_handler instead of the standard ; output_handler, or otherwise the output will be corrupted. zlib.output_compression = On Y por supuesto, podemos usar el mod_deflate, que nos comprime la salida generada por Wordpress sin problemas si lo tenemos configurado para que nos comprima los ficheros text/html: AddOutputFilterByType DEFLATE text/html Es recomendable no usar más de un método de compresión porque pueden chocar entre ellos. Sin embargo, todos estos métodos necesitan estar comprimiendo una y otra vez las mismas páginas. ¿Podríamos usar el mod_cache con alguno de estos métodos de compresión como hacíamos con contenidos estáticos y el mod_deflate? Pues desafortunadamente la respuesta es un no. Si tomamos una traza de red para ver qué cabeceras devuelve una petición enviada a un servidor de Wordpress: HTTP/1.1 200 OK Date: Sun, 02 Dec 2007 10:05:43 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7 Expires: Wed, 11 Jan 1984 05:00:00 GMT Last-Modified: Sun, 02 Dec 2007 10:05:44 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Keep-Alive: timeout=15, max=97 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 vemos que entre otras cosas, una respuesta con “Cache-Control: no-cache” no es cacheada por defecto en ningún caso, tal y como leemos en la Apache HTTP Server Version 2.2: Caching Guide: Likewise, if the response includes the “no-store” option in a “Cache-Control:” header, it will not be stored unless the CacheStoreNoStore has been used. Sin embargo, el contenido de Wordpress, aunque se genera dinámicamente, es bastante estático. Una entrada se escribe y a menos que se generen nuevos comentarios o el autor corrija algo, va a permanecer inalterable durante mucho tiempo. Debería de ser fácilmente cacheable… y en realidad así lo es gracias a distintos plugins. [...] Puedes leer el resto de la entrada en Comprimir y cachear las páginas generadas por Wordpress (1,234 palabras) Lo hice y lo entendí 2007 | © Vicente Navarro Jover con una licencia CC BY-SA | 10 comentarios Etiquetas: Apache, mod_cache, mod_deflate, mod_disk_cache, PHP, WordPress

You have already tagged this post. Your tags: