Detaillierte Erläuterung der Tomcat-Konfigurations- und Optimierungslösungen

Service.xml

Die Konfigurationsdatei Server.xml wird zum Konfigurieren des gesamten Containers verwendet.

<Server>-Element:

Ist das Stammelement der gesamten Konfigurationsdatei. Stellt den gesamten Catalina-Container dar.

Eigentum:

• className: Der Klassenname, der die Schnittstelle org.apache.catalina.Server implementiert. Die Standardimplementierungsklasse ist die Klasse org.apache.catalina.core.StandardServer.
• Port: Der Tomcat-Server wartet auf Befehle zum Herunterfahren des Tomcat-Servers (erforderlich)
• Shutdown: Der an den Port gesendete Befehl zum Herunterfahren des Tomcat-Servers.

Beispiel:

<Serverport="8005" shutdown="HERUNTERFAHREN">

<Connector>-Element:

Der Connector ist für den Empfang von Clientanforderungen und das Zurücksenden von Antwortnachrichten an den Client verantwortlich.

HTTP-Anschluss:

Eigentum:

• allowTrace: Gibt an, ob die HTTP TRACE-Methode zugelassen werden soll. Der Standardwert ist „false“.
• emptySessionPath: Wenn auf „true“ gesetzt, werden alle Pfade für den Benutzer auf / gesetzt. Standardmäßig auf „false“ gesetzt.
• enableLookups: Rufen Sie request und getRemoteHost() auf, um eine DNS-Abfrage durchzuführen und den Hostnamen des Remote-Hosts zurückzugeben. Wenn auf false gesetzt, wird die IP-Adresse direkt zurückgegeben.
• maxPostSize: Gibt die maximale Größe von POST-Anfragen an. Wenn nicht angegeben, ist der Standardwert 2097152.
• Protokoll: Der Wert muss HTTP1.1 sein. Wenn der AJP-Prozessor verwendet wird, muss der Wert AJP/1.3 sein.
• ProxyName: Wenn dieser Connector in einer Proxy-Konfiguration verwendet wird, geben Sie diese Eigenschaft an, die zurückgegeben wird, wenn request.getServerName() verwendet wird
• redirectPort: Wenn der Connector keine SSL-Anfragen unterstützt und eine SSL-Anfrage eingeht, leitet der Catalina-Container die angegebene Portnummer zur Verarbeitung automatisch um.
• Schema: Legt den Namen des Protokolls fest, das von request.getScheme() zurückgegeben wird. Für SSL-Anschlüsse ist „https“ eingestellt, der Standardwert ist „http“.
• secure: Dies kann in SSL-Konnektoren auf true gesetzt werden. Der Standardwert ist false
• URIEncoding: Die zum Dekodieren der URL verwendete Zeichenkodierung. Wenn nicht angegeben, ist der Standardwert ISO-8859-1.
• useBodyEncodingForURI: Wird hauptsächlich in Tomcat4.1.x verwendet und gibt an, ob zum Dekodieren von URI-Abfrageparametern die in contentType angegebene Kodierung anstelle von URIEncoding verwendet werden soll. Der Standardwert ist false
• xpoweredBy: Wenn true, verwendet Tomcat den von der Spezifikation empfohlenen Header, um die Unterstützung für die Servlet-Spezifikationsversion anzuzeigen. Der Standardwert ist false
• acceptCount: Die maximale Anzahl von Anfragen, die in die Warteschlange gestellt werden können, wenn alle möglichen Verarbeitungsthreads verwendet werden. Wenn die Warteschlange voll ist, werden alle empfangenen Anfragen abgelehnt. Der Standardwert ist 10
• bufferSize: Legt die Größe des vom Connector erstellten Eingabestreampuffers in Bytes fest. Standardmäßig beträgt die maximale Puffergröße 2048 Bytes.
• compressableMimeType: Eine Liste von MIME-Typen, standardmäßig durch Kommas getrennt. Die Standardwerte sind text/html, text/xml, text/plain
• Komprimierung: Gibt an, ob die Antwortdaten komprimiert werden sollen. aus: bedeutet, die Komprimierung zu deaktivieren, ein: bedeutet, die Komprimierung zuzulassen (der Text wird komprimiert), erzwingen: bedeutet, die Komprimierung in allen Fällen durchzuführen, der Standardwert ist aus
• connectionTimeout: Legen Sie den Verbindungs-Timeout-Wert in Millisekunden fest. Der Standardwert ist 60000 = 60 Sekunden
• disableUploadTimeOut: Ermöglicht dem Servlet-Container, einen längeren Verbindungstimeout-Wert zu verwenden, sodass das Servlet mehr Zeit hat, seine Ausführung abzuschließen. Der Standardwert ist „false“.
• maxHttpHeaderSize: Die maximale Größe des HTTP-Anforderungs- und Antwortheaders in Bytes. Der Standardwert beträgt 4096 Bytes.
• maxKeepAliveRequest: Die maximale Anzahl der vom Client gesendeten Pipelines, bevor der Server geschlossen wird. Der Standardwert ist 100
• maxSpareThreads: Die maximal zulässige Anzahl von Leerlauf-Threads. Der Standardwert ist 50
• minSpareThreads: Legt die Anzahl der Threads fest, die beim ersten Start des Connectors erstellt werden sollen, und stellt sicher, dass mindestens diese Anzahl an inaktiven Threads verfügbar ist. Der Standardwert ist 4
• Port: Die TCP-Portnummer, auf der der Server-Socket lauscht. Der Standardwert ist 8080 (erforderlich).
• socketBuffer: Legt die Größe des Socket-Ausgabepuffers fest (in Bytes). -1 bedeutet, dass die Pufferung deaktiviert ist. Der Standardwert beträgt 9000 Bytes.
• toNoDelay: Wenn wahr, kann dies die Leistung verbessern. Der Standardwert ist true.
• threadPriority: Legt die Priorität des Anforderungsverarbeitungsthreads in der JVM fest. Der Standardwert ist NORMAL-PRIORITY

Beispiel:

<Anschluss 
Port="8080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />

AJP-Anschluss:

Wird verwendet, um Apache mit Tomcat zu integrieren. Wenn Apache eine dynamische Inhaltsanforderung empfängt, sendet es die Anforderung an die AJP-Anschlusskomponente, die auf der in der Konfiguration angegebenen Portnummer lauscht.

Eigentum:

• Rückstand: Die maximale Anzahl von Anforderungen, die in die Warteschlange gestellt werden können, wenn alle möglichen Threads zur Anforderungsverarbeitung verwendet werden. Der Standardwert ist 10. Wenn die Warteschlange voll ist, wird jede Anfrage abgelehnt.
• maxSpareThread: Die maximal zulässige Anzahl an inaktiven Threads. Der Standardwert ist 50
• maxThread: Maximale Anzahl an Threads, der Standardwert ist 200
• minSpareThreads: Legen Sie die Anzahl der Threads fest, die beim ersten Start des Connectors erstellt werden sollen, und stellen Sie sicher, dass mindestens diese Anzahl an inaktiven Threads verfügbar ist. Der Standardwert ist 4
• Port: TCP-Portnummer des Server-Sockets, der Standardwert ist 8089 (erforderlich)
• topNoDelay: Wenn true, kann dies die Leistung verbessern. Der Standardwert ist true
• soTimeout: Timeout-Wert

Beispiel:

<!—Definieren Sie einen AJP1.3-Connector auf Port 8089-->
<Connector-Port = „8089“ enableLookups = „false“ redirectPort = „8443“ Protokoll = „AJP/1.3“ />

<Engine>-Element:

Bearbeitet alle Anfragen für einen bestimmten Dienst. Jeder Dienst kann nur ein Engine-Element enthalten, das für den Empfang und die Verarbeitung der von allen Konnektoren dieses Dienstes empfangenen Anfragen, das Zurücksenden von Antworten an die Verbindungen und deren schließliche Anzeige auf dem Client verantwortlich ist. <Engine> muss mindestens ein <Host>-Element haben, und es muss mindestens ein <Host>-Attribut mit einem Namen vorhanden sein, der mit dem von defaultHost angegebenen Namen übereinstimmt.

Eigentum:

• className: implementiert die Schnittstelle org.apache.catalina.Engine. Die Standardimplementierungsklasse ist die Klasse org.apache.catalina.core.StandardEngine.
• defaultHost: Der Standardhostname. Der Wert muss mit dem Namenswert von <Service> übereinstimmen.
• Name: Gibt den logischen Namen der Engine an (erforderlich)
• jvmRoute: Kennung, die beim Lastenausgleich verwendet wird, muss eindeutig sein

Beispiel:

<Engine-Name="Cataline" Standardhost="localhst">

<Host>-Element:

Stellt einen virtuellen Host dar und verarbeitet alle Anfragen für einen bestimmten virtuellen Host

Eigentum:

• appBase: Legen Sie das Basisverzeichnis der Anwendung fest, absoluter Pfad oder Pfadname relativ zu %CATALINA_HOME%
• autoDeploy: Gibt an, ob neue Webprogramme automatisch in das von appBase angegebene Verzeichnis bereitgestellt werden sollen, wenn Tomcat ausgeführt wird. Der Standardwert ist true
• className: Die Klasse, die die Schnittstelle org.apache.catalina.Host implementiert. Die Standardimplementierungsklasse ist die Klasse org.apache.catalina.core.StandardHost.
• deployOnStartup: Gibt an, ob beim Start von Tomcat automatisch alle Webanwendungen im durch das Attribut appBase angegebenen Verzeichnis bereitgestellt werden sollen. Der Standardwert ist true
• Name: Der Netzwerkname des virtuellen Hosts (erforderlich)

Die Standard-Host-Implementierungsklasse org.apahce.catalina.core.StandardHost unterstützt zusätzliche Eigenschaften:

• deployXML: false analysiert die context.xml nicht innerhalb der WEB-Anwendung. Der Standardwert ist true
• unPackWARs: Der virtuelle Host gibt den Pfadnamen des Verzeichnisses an, das zum temporären Lesen und Schreiben verwendet wird. Wenn nicht festgelegt, stellt Tomcat ein geeignetes Verzeichnis im Verzeichnis %CATALINA_HOME%/work bereit.

Beispiel:

<Hostname="localhst" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">

Konfigurieren Sie den virtuellen Host:

<Hostname="xxx" appBase="c:/test">
<Contentpath="" docBase="e:/abe"/>
</Hostname>

<context>-Element:

Eine Webanwendung verarbeitet alle Anforderungen für die aktuelle Webanwendung. Jeder <Kontext> muss einen eindeutigen Kontextpfad verwenden.

Eigentum:

• className: Klasse, die die Schnittstelle org.apache.catalina.Context implementiert, Standardimplementierungsklasse org.apache.catalina.core.StandardContext-Klasse
• Cookies: Gibt an, ob das Cookie auf die Sitzung angewendet werden soll. Der Standardwert ist „true“.
• crossContext: Gibt an, ob domänenübergreifender Zugriff zulässig ist. Wenn diese Option auf „true“ gesetzt ist, gibt der Aufruf der Methode ServletContext.getContext() innerhalb des Programms einen Anforderungsdispatcher für andere Webprogramme auf einem virtuellen Host zurück. Der Standardwert ist „false“ und getContext() gibt „null“ zurück.
• docBase: absoluter Pfad oder relativer Pfad zur appBase-Eigenschaft des Hosts
• privilegiert: true, wodurch die Webanwendung das Servlet des Containers verwenden kann
• Pfad: Gibt den Kontextpfad an. Der Kontextpfad muss innerhalb eines virtuellen Hosts eindeutig sein.
• reloadable: True. Wenn Tomcat ausgeführt wird und es Änderungen in den Verzeichnissen WEB-INF/classes und WEB-INF/lib gibt, lädt Tomcat die WEB-Anwendung automatisch neu. Obwohl es praktisch ist, sind die Kosten auch hoch. Der Standardwert ist „false“. Wir können es während des Anrufs einschalten und nach der Veröffentlichung ausschalten.
• cacheMaxSize: Maximalwert des statischen Ressourcencaches in KB, der Standardwert beträgt 10240 KB
• cachingAllowed: Gibt an, ob das Zwischenspeichern statischer Ressourcen zugelassen werden soll. Der Standardwert ist „true“.
• caseSensitive: Der Standardwert ist true, der Ressourcendateiname ist case-sensitiv, wenn er false ist, ist case-sensitiv
• unpackWAR: Standard ist true
• workDir: Gibt den temporären Lese-/Schreibverzeichnispfadnamen für das Servlet innerhalb der Webanwendung an. Wenn nicht festgelegt, stellt Tomcat ein geeignetes Verzeichnis im Verzeichnis %CATALINA_HOME%/work bereit.

Beispiel:

<Inhaltspfad=”/abc” docBase=”d:/xyz” reloadable=”true” />

Zusammenfassung der Tomcat-Leistungsoptimierungslösung

Stellen Sie sich folgendes Szenario vor: Sie haben eine App mit hervorragendem Layout-Design, den neuesten Funktionen und anderen tollen Features entwickelt. Wenn jedoch die Leistung fehlt, wird die Anwendung von den Kunden abgelehnt, egal wie gut sie ist. Kunden erwarten von ihren Anwendungen stets eine bessere Leistung.

Wenn Sie in Ihrem Produkt einen Tomcat-Server verwenden, zeigt Ihnen dieser Artikel mehrere Möglichkeiten zur Verbesserung der Leistung des Tomcat-Servers. Vielen Dank an ITWorld für die Bereitstellung der Ressourcen für diesen Artikel. Nach einigem Nachdenken bin ich zu dem Schluss gekommen, dass der neueste Tomcat im Vergleich zu früheren Versionen eine bessere Leistung und Stabilität bietet. Verwenden Sie daher immer die neueste Tomcat-Version. Dieser Artikel verwendet die folgenden Schritte, um die Leistung des Tomcat-Servers zu verbessern.

• Erhöhen Sie die Größe des JVM-Heapspeichers
• JRE-Speicherleck beheben
• Thread-Pool-Einstellungen
• Kompression
• Optimierung der Datenbankleistung
• Native Tomcat-Bibliothek
• Andere Optionen

Schritt 1 – JVM-Heapspeicher erhöhen

Wenn Sie Tomcat verwendet haben, nennt man das einfach „Speicherüberlauf“. Normalerweise tritt dieses Problem in der tatsächlichen Produktionsumgebung auf. Der Grund für dieses Problem ist, dass Tomcat für den Prozess weniger Speicher verwendet. Dieses Problem kann durch Konfigurieren der Tomcat-Konfigurationsdatei (catalina.bat unter Windows oder catalina.sh unter Linux) gelöst werden. Diese Lösung wird durch Erhöhen des Stapelspeichers der JVM erreicht. Mit anderen Worten, die JVM ruft den Garbage Collector normalerweise nicht auf, sodass sich der Server mehr auf die Verarbeitung von Webanforderungen konzentrieren und diese so schnell wie möglich abschließen kann. Um die Datei (catalina.sh) im Ordner „\tomcat server folder\bin\catalina.sh“ zu ändern, finden Sie im Folgenden die Konfigurationsinformationen für diese Datei.

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8
-server -Xms1024m -Xmx1024m
-XX:NeueGröße=512m -XX:MaximaleNeueGröße=512m -XX:PermanenteGröße=512m
-XX:MaxPermSize=512m -XX:+DisableExplicitGC"
-Xms – gibt den zu initialisierenden Stapelspeicher an -Xms – gibt den zu initialisierenden Stapelspeicher an -Xmx – gibt den maximalen Stapelspeicher an

Diese Konfigurationsänderungen werden erst wirksam, wenn Sie Ihren Tomcat-Server neu starten. Nachfolgend wird der Umgang mit JRE-Speicherlecks beschrieben.

Schritt 2 – JRE-Speicherleck beheben

Ein weiterer Hauptgrund für schlechte Leistung sind Speicherlecks, und wie ich bereits sagte: Verwenden Sie für bessere Leistung und Skalierbarkeit immer den neuesten Tomcat-Server. Nun ist dieser Satz wahr geworden. Wenn wir die neueste Tomcat-Version 6.0.26 und höher verwenden, können wir diesen Fehler beheben, da sie einen Listener zum Behandeln von Speicherlecks in JRE und PermGen enthält. Der verwendete Listener ist

<Listener-Klassenname="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

Die Konfiguration dieses Listeners finden Sie in der Datei server.xml, die sich im Ordner „Tomcat-Projektordner/conf/server.xml“ befindet. Als nächstes schauen wir uns an, wie die Verbindungseigenschaft „maxThreads“ angepasst wird.

Schritt 3 – Thread-Pool-Setup

Der Thread-Pool gibt die Anzahl der Web-Anforderungsladungen an, daher sollte dieser Teil für eine bessere Leistung sorgfältig behandelt werden. Dies kann durch Anpassen der Connector-Eigenschaft „maxThreads“ erfolgen. Der Wert von maxThreads sollte auf der Größe des Datenverkehrs basieren. Wenn der Wert zu niedrig ist, gibt es nicht genügend Threads, um alle Anforderungen zu verarbeiten. Die Anforderung wechselt in einen Wartezustand und wird erst verarbeitet, wenn ein Verarbeitungsthread freigegeben wird. Wenn der Wert zu hoch eingestellt ist, dauert der Start von Tomcat länger. Es liegt also an uns, einen korrekten Wert für maxThreads festzulegen.

<Connector-Port="8080" Adresse="localhost"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" Protokoll="HTTP/1.1"
enableLookups="false" redirectPort="8181" acceptCount="100"
Verbindungs-Timeout = "20000" Deaktivieren Sie Upload-Timeout = "true" />

In der obigen Konfiguration ist der maxThreads-Wert auf „250“ eingestellt, was die maximale Anzahl gleichzeitiger Anfragen angibt, die vom Server verarbeitet werden können. Wenn nicht angegeben, ist der Standardwert dieser Eigenschaft „200“. Bei allen weiteren gleichzeitigen Anforderungen wird die Fehlermeldung „Verbindung abgelehnt“ angezeigt, bis ein anderer Prozess zur Bearbeitung der Anforderung freigegeben wird. Der Fehler sieht so aus:

org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: Alle Threads (250) sind
Momentan beschäftigt, warte. Erhöhen Sie maxThreads (250) oder überprüfen Sie den Servlet-Status

Wenn die Anwendung den oben genannten Fehler anzeigt, prüfen Sie, ob der oben genannte Fehler durch eine einzelne Anfrage verursacht wird, die zu lange dauert. Der Grund für dieses Problem ist, dass der Prozess manchmal keine anderen Anfragen verarbeitet, wenn die Datenbankverbindung nicht freigegeben wird.

Hinweis: Wenn die Anzahl der Anfragen „750“ überschreitet, bedeutet dies nicht, dass der Attributwert „maxThreads“ auf „750“ gesetzt werden muss, sondern dass es besser ist, mehrere Instanzen von „Tomcat Cluster“ zu verwenden. Das heißt, wenn es „1000“ Anfragen gibt, setzen beide Tomcat-Instanzen „maxThreads = 500“, anstatt im Fall einer einzelnen Tomcat-Instanz „maxThreads = 1000“ zu setzen.

Meiner Erfahrung nach kann der genaue Wert ermittelt werden, indem die Anwendung in verschiedenen Umgebungen getestet wird. Als Nächstes schauen wir uns an, wie MIME-Typen komprimiert werden.

Schritt 4 - Komprimierung

Tomcat bietet eine Option zum Aktivieren der Komprimierung, indem Sie diese in der Konfigurationsdatei server.xml festlegen. Die Komprimierung kann in den Connector-Einstellungen wie unten beschrieben erfolgen.

 <Anschlussport="8080" Protokoll="HTTP/1.1"
 VerbindungsTimeout="20000"
 UmleitungsPort="8181" Komprimierung="500"
 compressableMimeType="text/html,text/xml,text/plain,anwendung/octet-stream" />

In der vorherigen Konfiguration werden Dateien nur komprimiert, wenn ihre Größe größer oder gleich 500 Byte ist. Wenn die Datei beim Erreichen der erforderlichen Größe nicht komprimiert wird, setzen Sie die Eigenschaft „compression=on“. Andernfalls ist die Tomcat-Standardeinstellung „Aus“. Als Nächstes schauen wir uns an, wie die Datenbank optimiert wird.

Schritt 5 – Optimierung der Datenbankleistung

Die Leistung von Tomcat nimmt ab, während auf die Ausführung von Datenbankabfragen gewartet wird. Die meisten Anwendungen verwenden heutzutage eine relationale Datenbank, die „benannte Abfragen“ enthalten kann. In diesem Fall lädt Tomcat benannte Abfragen standardmäßig beim Start, was die Leistung verbessern kann. Außerdem muss sichergestellt werden, dass alle Datenbankverbindungen ordnungsgemäß geschlossen werden. Es ist auch sehr wichtig, den richtigen Wert für den Datenbankverbindungspool festzulegen. Die Werte, von denen ich spreche, sind die Werte der Attribute „Maximale Leerlaufzahl“ (maxIdle), „Maximale Verbindungsanzahl“ (maxActive) und „Maximale Wartezeit für den Verbindungsaufbau“ (maxWait) des Ressourcenelements. Aufgrund von Konfigurationsabhängigkeiten und Anwendungsanforderungen kann ich in diesem Artikel nicht die richtigen Werte angeben. Den richtigen Wert können Sie durch den Aufruf des Datenbank Performancetests ermitteln.

Schritt 6 – Tomcat Native Library

Die native Bibliothek von Tomcat basiert auf der Apache Portable Runtime (APR), die Programmierern überlegene Skalierbarkeit und Leistung bietet und dabei hilft, native Servertechnologie in den Produktbetrieb zu integrieren, um optimale Leistung zu erzielen. Installationsanweisungen finden Sie unter Tomcat Native Library – (APR) Installation.

Schritt 7 – Andere Optionen

Die Optionen sind:

• Aktivieren Sie das Browser-Caching, damit statische Inhalte, die im Ordner „Webapps“ gespeichert sind, schneller gelesen werden können. Dies verbessert die Gesamtleistung erheblich.
• Der Tomcat-Server sollte bei jedem Booten automatisch neu gestartet werden.
• Im Allgemeinen sind HTTPS-Anfragen langsamer als HTTP-Anfragen. Wenn Sie eine bessere Sicherheit wünschen, sollten Sie HTTPS wählen, auch wenn es langsamer ist.

Stellen Sie TOMCAT so ein, dass die GZIP-Komprimierung aktiviert wird

Prinzip Einführung

HTTP-Komprimierung kann die Geschwindigkeit beim Surfen auf Websites erheblich verbessern. Das Prinzip besteht darin, dass, nachdem der Client die entsprechenden Ressourcen vom Server angefordert hat, die Ressourcendatei vom Server komprimiert und dann an den Client ausgegeben wird. Der Browser des Clients ist für das Dekomprimieren und Surfen verantwortlich.

Im Vergleich zum normalen Browsing-Prozess mit HTML, CSS, Javascript und Text können etwa 40 % des Datenverkehrs eingespart werden. Noch wichtiger ist, dass es dynamisch generierte Webseiten komprimieren kann, einschließlich der von CGI, PHP, JSP, ASP, Servlet, SHTML usw. ausgegebenen Seiten, und dass die Komprimierungseffizienz ebenfalls sehr hoch ist.

Konfigurationsmethode

Tomcat 5.0 und spätere Versionen unterstützen die Komprimierung von Ausgabeinhalten mithilfe des GZIP-Komprimierungsformats.

Ändern Sie %TOMCAT_HOME%/conf/server.xml und überarbeiten Sie die Knoten wie folgt:

<Anschluss-Port="80" Protokoll="HTTP/1.1" 
VerbindungsTimeout="20000" 
UmleitungsPort="8443" Executor="tomcatThreadPool" URIEncoding="utf-8" 
Komprimierung="ein" 
KompressionMinSize="50" keineKompressionBenutzerAgents="gozilla, traviata" 
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />

Wie aus den Eigenschaften der obigen Knoten ersichtlich ist, müssen Sie zur Verwendung der GZIP-Komprimierungsfunktion dem Connector-Knoten die folgenden Eigenschaften hinzufügen

• compression="on" schaltet die Komprimierung ein
• compressionMinSize="50" aktiviert komprimierte Ausgabeinhaltsgröße, Standard ist 2 KB
• noCompressionUserAgents="gozilla, traviata" Für die folgenden Browser ist die Komprimierung nicht aktiviert
• compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" Welche Ressourcentypen müssen komprimiert werden?

Testmethode

Wie testen wir, ob die Komprimierung effektiv ist, nachdem wir die TOMCAT-Komprimierungsfunktion aktiviert haben?

Zunächst ermittelt Tomcat anhand der Accept-Kodierung im Browser-Anforderungsheader, ob der Browser Komprimierung unterstützt. Wenn dieser Wert gzip enthält, bedeutet dies, dass der Browser das Durchsuchen von gzip-komprimierten Inhalten unterstützt. Wir können zwei Methoden verwenden, um zu überprüfen, ob die Komprimierung wirksam ist.

Sie können über den Browser direkt auf den Server mit aktivierter Komprimierungskonfiguration zugreifen und dann die erfassten Datenpakete über das Paketerfassungstool anzeigen. Wenn viele Inhalte vorhanden sind, die Sie nicht verstehen, bedeutet dies, dass die Komprimierungsfunktion aktiviert wurde.

Anfragen durch Programme simulieren

Wir verwenden httpclient, um ein einfaches Testprogramm zu schreiben. Der Code lautet wie folgt:

@Prüfen 
öffentliche Leere testGzip() { 
HttpClient httpClient = neuer HttpClient(); 
GetMethod getMethod = neue GetMethod("http://localhost/admin.jsp"); 
versuchen { 
getMethod.addRequestHeader("accept-encoding", "gzip,deflate"); 
getMethod.addRequestHeader("user-agent","Mozilla/4.0 (kompatibel; MSIE 6.0; Windows NT 5.0; Alexa Toolbar; Maxthon 2.0)"); 
int result = httpClient.executeMethod(getMethod); 
wenn (Ergebnis == 200) { 
System.out.println(getMethod.getResponseContentLength()); 
String html = getMethod.getResponseBodyAsString(); 
System.out.println(html); 
System.out.println(html.getBytes().length); 
} 
} Fang (HttpException e) { 
e.printStackTrace(); 
} Fang (IOException e) { 
e.printStackTrace(); 
Endlich 
: Gibt an, ob die Verbindung freigegeben wurde. 
} 
}

Führen Sie dieses JUnit-Programm aus und sehen Sie, was es ausgibt. Wenn die Ausgabe einige verstümmelte Zeichen enthält und die Länge des gedruckten Inhalts viel kleiner als die tatsächliche Länge ist, bedeutet dies, dass unsere Konfiguration wirksam ist. Durch einige andere Überprüfungstools werden Sie feststellen, dass die Geschwindigkeit beim Surfen auf der Website erheblich verbessert wird.

Hinweis: Wenn Sie feststellen, dass der Inhalt nicht komprimiert ist, können Sie die Größe „compressionMinSize“ anpassen. Wenn die angeforderte Ressource kleiner als dieser Wert ist, wird die Komprimierung nicht aktiviert.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.