java - como - descargar apache tomcat 9

La compresión de Tomcat no agrega una codificación de contenido: gzip en el encabezado

Question

Estoy usando Tomcat para comprimir mi contenido HTML de esta manera:

<Connector port="8080" maxHttpHeaderSize="8192"
maxProcessors="150" maxThreads="150" minSpareThreads="25"
maxSpareThreads="75" enableLookups="false" redirectPort="8443"
acceptCount="150" connectionTimeout="20000" disableUploadTimeout="true"
compression="on" compressionMinSize="128" noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html"
URIEncoding="UTF-8" />

En el encabezado HTTP (como se observa a través de YSlow), sin embargo, no estoy viendo

Content-Encoding: gzip

lo que resulta en una baja puntuación de YSlow.

Todo lo que veo es

HeadersPost
Response Headers
Server: Apache-Coyote/1.1
Content-Type:   text/html;charset=ISO-8859-1
Content-Language:   en-US
Content-Length: 5251
Date:   Sat, 14 Feb 2009 23:33:51 GMT

Estoy ejecutando una configuración de apache mod_jk Tomcat.

¿Cómo comprime el contenido HTML con Tomcat y también le pido que agregue "Content-Encoding: gzip" en el encabezado?

Answer 1

¿Quizás la compresión a la que se refiere Tomcat no es gzip? Es una puñalada en la oscuridad, pero podría estar relacionada con la compresión del espacio en blanco o el recorte de la línea.

Me imagino que Tomcat sería un poco más explícito a este respecto (aquí está la esperanza).

Tenemos el filtro gzip mencionado por duffmo corriendo en nuestra aplicación, el web.xml se ve así:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-app_2_4.xsd">

    <display-name>App-Web</display-name>

    <!-- FILTERS -->

    <!-- Gzip filter -->
    <filter>
        <filter-name>GZIPFilter</filter-name>
        <filter-class>weblogicx.servlet.gzip.filter.GZIPFilter</filter-class>
    </filter>

    [snip]    
</web-app>

Answer 2

Eche un vistazo a http://sourceforge.net/projects/pjl-comp-filter/ .

Otras soluciones personalizadas pueden tener pérdidas de memoria.

Además, si está utilizando mod_jk, entonces ciertamente no está usando el conector 8080 (que admite compresión) para esas solicitudes.

Answer 3

Para mejorar el rendimiento general del lado del cliente de la aplicación web J2EE, puede probar la biblioteca web de WebUtilities.

Aquí está el enlace :: http://code.google.com/p/webutilities/ .

Proporciona componentes de filtro, etiqueta y servlet para aplicar diversas prácticas de rendimiento del lado del cliente, lo que da como resultado una calificación de rendimiento más alta frente a PageSpeed ​​/ YSlow.

Desde la versión 0.0.4, ayuda con las siguientes prácticas de rendimiento.

1. Minimice las solicitudes HTTP: puede servir varios archivos JS / CSS en una sola solicitud
2. Almacenamiento en caché del lado del cliente: agrega el control de caché adecuado, encabezado Expira
3. Sobre la marcha Minificación JS / CSS - usando YUICompressor
4. Compresión: admite compresión de 2 vías para gzip / desinflar / comprimir codificaciones
5. Caché de respuesta en el servidor: para evitar el reprocesamiento de recursos sin cambios
6. Agregar codificación de caracteres: para que el navegador lo sepa con anticipación

También es altamente configurable / personalizable contra MIME, URL o User-Agents.

Answer 4

Eché un vistazo a la documentación de Tomcat aquí: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

Menciona el uso de compression="force" que funcionó para mí. También dice que puedes establecer un minimum number . Esto funcionó bien para mi

<Connector port="8080" compression="256000" />

(comprima cualquier cosa superior a 256 Kb)

El valor predeterminado para compressableMimeType significaba que no necesitaba ese atributo. También tenga en cuenta que no enumera el atributo CompressionMinSize .

Answer 5

Tomcat hará la compresión. Sin embargo, debido a que está utilizando mod_jk , supongo que obtendrá sus solicitudes a través de Apache en el puerto 80 en lugar de Tomcat en el puerto 8080 . Como experimento, intente obtener su página a través del puerto 8080 y luego revise yslow , debería ver los encabezados correctos.

Creo que lo que está sucediendo es que apache está descomprimiendo el contenido que está obteniendo de tomcat a través de mod_jk y luego pasando el contenido desinflado al navegador.

Si desea usar mod_jk , deberá configurar su compresión en Apache en lugar de Tomcat.