PCMasters.de

Die Version 1.0.34

das Modul mod_accel ist für die Nutzung Apache im Regime des Gaspedals vorbestimmt, das heißt, er realisiert die Funktionalität ProxyPass des Bausteines mod_proxy. Jedoch wirkt im Unterschied zu zusammen mod_proxy richtig berücksichtigen, mod_accel (ausführlicher darüber niedriger), kann bei cookie, "busy lock" verwenden und, die Zahl der Verbinden beschränken, lässt zu, in den Hohlweg die Ergebnisse der Arbeit und endlich die Antworten mod_accel zu speichern können. Apache sein und sind vom Baustein mod_deflate zusammengepresst.

das Modul mod_accel kann im Regime des gewöhnlichen Proxy-Servers wie mod_proxy nicht arbeiten. Jedoch ist es kaum zweckmässig, Apache in dieser Qualität anstelle Squid und Oops zu verwenden. Nichtsdestoweniger, es oft es beim Konfigurieren mod_proxy zusammen mit der Funktionalität des Gaspedals aus Versehen erlauben standardmäßig Proxy (ProxyRequests on), was zum Erscheinen des nächsten öffentlichen Proxy-Servers bringt. Und zur gleichen Zeit, die Nutzung Squid oder Oops als Gaspedal weniger bequem, als Apache, da Apache gewöhnlich ohne Proxy die Abfragen auch bearbeiten kann.

mod_accel Stellt von sich eigentlich den Baustein, der Apache EAPI verwendet, und für Apache und das Modul mod_proxy, mod_rewrite, mod_ssl und mod_charset (Russian Apache) vor. Außerdem gibt es im Distributionssatz drei Bausteine - mod_randban, mod_quoted und mod_freeze, abändernd den Körper der übergebenen Antwort. Erster ändert den zufälligen Wert in URL'ах für den Aufruf der Banner, zweiten re-codiert die russischen Symbole in den Konstruktionen der Art ' <a href = "/show? %80%81%82"> ', und ändert dritter einige aktiv Tags und die Parameter.

Der Inhalt

Die Installation
Das dynamische Laden
Wie es arbeitet
Wenn die Antwort aus dem Cache bekommen sein kann
Busy lock
Die Beschränkung der Zahl der Abfragen
Die primitive Zuordnung der Belastung und Fehler Resistanz
Welche Antworten Caching
Die Notizen, mit deren Hilfe man den Baustein verwalten kann
Wie mit cookie zu arbeiten
Dass man in den Hohlweg speichern kann
Das Reinigen des Caches
Die Direktiven

AccelAddVia

AccelAddXForwardedFor

AccelBkRcvBuffSize

AccelBkRcvSockBuffSize

AccelCleanLastAccessed

AccelLastModifiedFactor

AccelMaxStale

AccelModRewriteLocation

AccelWaitBeforeBodyRead

Die bekannten Fehler und die Besonderheiten
Der Manager des Caches
das Modul mod_randban

Die Wechselwirkung mit dem Baustein mod_rewrite
Die Anpassung der Produktivität
Wie mod_proxy mit Backend zusammenwirkt

Die Installation

Den Distributionssatz muss man auspacken, in den Katalog mit den Ausgangstexten übergehen und, den Befehl ausführen ./configure, Ihr den Pfad zu ausgangs- den Texten Apache und EAPI bezeichnet. Nach dem Konfigurieren muss man den Befehl ausführen make:

tar zxf mod_accel-1.0.34.tar.gz 
cd mod_accel-1.0.34 
./configure 
    - with-apache = <apache_dir> 
    - with-eapi = <eapi_dir> 
make

Die Ausgangstexte EAPI kann man aus dem Distributionssatz mod_ssl nehmen, das Modul mod_ssl muss dabei nicht, feststellen, zum Beispiel:

./configure 
    - with-apache =./apache_1.3.20 
    --with-eapi=../mode_ssl-2.8.4-1.3.20/pkg.eapi

Wenn sich Apache mit der Nutzung des Bausteines mod_ssl, so der Parameter versammeln wird --with-eapi Ist nicht nötig, da mod_ssl Apache EAPI selbst feststellt.

Man muss bemerken, dass die Versionen EAPI, die im Bestand mod_ssl-2.8.13-1.3.27 gehen und mod_ssl-2.8.14-1.3.27 nicht mit dem geteilten Gedächtnis richtig arbeiten, das bei der Nutzung busy lock'ов und die Beschränkung der Zahl der Verbinden und die wartenden Prozesse notwendig ist. Deshalb, seit der Version 1.0.28, mod_accel beim Konfigurieren prüft das Vorhandensein EAPI mit den Fehlern und patchт es falls notwendig.

Unter Anwendung von den Bausteinen mod_charset oder mod_ssl sie muss man bis zu mod_accel feststellen, da es bei der Installation mod_accel diese Bausteine patchть notwendig ist. mod_ssl ist es empfehlenswert, festzustellen so, wie es im Abschnitt "The flexible APACI-only way [FOR REAL HACKERS]" der Datei INSTALL aus dem Distributionssatz mod_ssl beschrieben ist.

Beim Konfigurieren kann man noch etwas Parameter bezeichnen:

--with-mod_randban - Den Ausgangstext des Bausteines mod_randban in den Katalog festzustellen <apache_dir>/src/modules/extra/;
--with-mod_quoted - Den Ausgangstext des Bausteines mod_quoted in den Katalog festzustellen <apache_dir>/src/modules/extra/;
--with-mod_freeze - Den Ausgangstext des Bausteines mod_freeze in den Katalog festzustellen <apache_dir>/src/modules/extra/;
--without-mod_rewrite - Nicht patch das Modul mod_rewrite;
--without-cachemgr - cachemgr nicht zu sammeln. Der Parameter ist in der Version 1.0.2 erschienen;
--with-patch=<path_to_patch> - Das angegebene Programm zu verwenden patch. Der Parameter ist in der Version 1.0.7 erschienen.

Seit der Version 1.0.7, die Parameter --without-mod_charset Und --without-mod_ssl Werden nicht unterstützt.

Die Mannschaft make Legt patch auf die Ausgangstexte Apache und das Modul mod_proxy, mod_rewrite, mod_charset und mod_ssl auf, stellt bei Notwendigkeit Apache EAPI fest und kopiert die Ausgangstexte des Bausteines mod_accel in den Katalog <apache_dir>/src/modules/accel/. Außerdem wenn die zusätzlichen Bausteine mod_randban angegeben sind, mod_quoted oder mod_freeze jenes werden sie in den Katalog kopiert <apache_dir>/src/modules/extra/.

Wenn es angenommen wird, busy lock und die Beschränkung der Zahl der Verbinden zu verwenden und ist der wartenden Prozesse, so muss man auch die Bibliothek mm (sie feststellen an die Adresse http://www.engelschall.com/sw/mm/) zugänglich:

tar zxf mm-1.2.1.tar.gz 
cd mm-1.2.1 
./configure - disable-shared 
make

Mit dem Parameter --disable-shared Die Bibliothek wird statisch gesammelt sein. Die Bibliothek kann man dynamisch sammeln, aber in diesem Fall muss man nach der Montage sie von der Mannschaft feststellen make install.

Beim Konfigurieren Apache muss man die Bausteine, EAPI und EAPI_MM (aktivieren wenn wird die Bibliothek mm verwendet):

cd <apache_dir> 
EAPI_MM = <mm_dir>./configure 
    ...
    - enable-rule=EAPI 
    --activate-module=src/modules/extra/mod_randban.o 
    --activate-module=src/modules/extra/mod_quoted.o 
    --activate-module=src/modules/extra/mod_freeze.o 
    --activate-module=src/modules/accel/libaccel.a 
    ...

Bis zu Version mod_accel soll der 1.0.7 Baustein mod_accel nach den Bausteinen mod_quoted und mod_randban angegeben sein. Seit der Version 1.0.7, die Ordnung hat den Wert nicht. Falls die Bibliothek mm dynamisch, variabel gesammelt ist EAPI_MM Wird so aussehen:

EAPI_MM=SYSTEM

Nach der Installation Apache muss man den Katalog machen, in dem die Dateien des Caches und die temporären Dateien erstellt werden werden. Der Benutzer, von dessen Namen die Prozesse Apache arbeiten, sollen zur Lektüre und der Aufnahme in diesen Katalog sein rechtskräftig. Diesen Katalog muss man in der Direktive AccelCacheRoot, zum Beispiel, bezeichnen:

AccelCacheRoot cache

Das dynamische Laden

das Modul mod_accel kann dynamisch geladen werden. Seit der Version 1.0.7, die Ordnung des Ladens hat den Wert nicht.

Bis zur Version 1.0.7, wie auch bei der statischen Montage, das Modul mod_accel soll nach den Bausteinen mod_quoted und mod_randban angegeben sein:

LoadModule randban_module modules/mod_randban.so 
LoadModule quoted_module modules/mod_quoted.so 
LoadModule accel_module modules/libaccel.so

Wenn das Modul mod_ssl dynamisch auch geladen wird, so soll er bis zum Baustein mod_accel (es auch angegeben sein hat den Wert, seit der Version 1.0.7) nicht:

LoadModule ssl_module modules/libssl.so 
LoadModule accel_module modules/libaccel.so

Wie es arbeitet

In der Phase der Assemblierung URI mod_accel prüft, ob der Anfang URI c von irgendwelchem des Präfixes, der Direktiven in der Liste angegebenen AccelPass übereinstimmt. Wenn das Zusammenfallen gefunden ist, so wird die Liste der Direktiven AccelNoPass durchgesehen. Wenn in dieser Liste kein Präfix oder der regelmäßige Ausdruck, entsprechend URI gefunden ist, so wird ein Handler dieser Abfrage "accel-handler", der diese Abfrage auf anderen Server richten wird. Zum Beispiel, die Abfrage "http://frontend/test/one.cgi?test=1" die Direktive

AccelPass/test/http://backend/test/

Wird in die Abfrage "http://backend/test/one.cgi?test=1" umwandeln.

Wenn die Antwort auf die Abfrage verschlüsselt sein kann, so wird sein Vorhandensein im Cache geprüft. Schlüssel für die Suche im Cache ist das Ergebnis der chesch-Funktion md5, als deren Argument umgewandelt URL, für unseren Fall "http://backend/test/one.cgi?test=1" übergeben wird. Wenn die Antwort im Cache gefunden ist, so wird er von den Blöcken ausgelesen, deren Umfang mit der Direktive AccelCacheSendSize protzt und wird dem Klienten zurückgegeben.

Wenn es keine Antwort gibt, oder ist er veraltet, oder die Antwort überhaupt неcached, so soll die Abfrage Backend übergeben sein. Nach ihm werden busy lock, die Zahl der Verbinden mit Backend und die Zahl der wartenden Prozesse geprüft . Dann, wenn die Abfrage einen Körper (zum Beispiel, die Abfrage der Art POST hat), so wird es in den Puffer ausgelesen, dessen Umfang mit der Direktive AccelRequestBuffSize protzt. Wenn der Körper der Abfrage den Umfang des Puffers übertritt, so wird es in die temporäre Datei gespeichert. Und nur verbindet sich danach mod_accel mit Backend (oder mit einem von ihnen), übergibt ihm die Abfrage und dann liest den Kopfteil der Antwort. Socketы Backend und des Klienten werden ins nicht blockierende Regime übersetzt und dem Klienten wird der Kopfteil der Antwort übergeben. Danach wird der Körper der Antwort in den Puffer der Aufnahme der Antwort gelesen, dessen Umfang mit der Direktive AccelBkRcvBuffSize protzt. Kaum wird der Umfang abgelesen gleich dem Umfang dieses Puffers, es wird die temporäre Datei erstellt und in ihn wird der Inhalt des Puffers gespeichert. Je nach dem Erhalten der Antwort wird er dem Klienten von den Blöcken vom Umfang zurückgegeben, der von der Direktive AccelSendSize aufgegeben ist.

Im Laufe der Sendung der Antwort dem Klienten kann er von der Kette das Modul, zum Beispiel, von den Bausteinen mod_randban, mod_quoted und mod_freeze abgeändert werden .

Kaum ist die Antwort von Backend vollständig bekommen, Socket Backend wird geschlossen, und Socket des Klienten wird ins sperrende Regime übersetzt. Danach kann die Antwort ins Cache gespeichert sein und kann von anderen Prozessen Apache verwendet werden.

Wenn die Antwort aus dem Cache bekommen sein kann

Bevor die Abfrage Backend übergeben sein wird, wird das Vorhandensein der Antwort im Cache geprüft. Es geschieht in der folgenden Ordnung:

Wenn die Direktive AccelNoCache oder die Abfrage nicht der Art GET oder HEAD aktiv ist, so wird er Backend übergeben und wird die Notiz "accel_st" "PASS" gleich sein.
Wenn die Notiz "accel_nocache" oder die variabelen "ACCEL_NOCACHE - Umgebungen bestimmt ist, so wird die Abfrage Backend übergeben und wird die Notiz"accel_st""NTNC"gleich sein.
Danach wird der Kopfteil "Authorization" geprüft. Wenn die Direktiven AccelIgnoreAuth und AccelRevalidateUser nicht aktiv sind, so wird die Abfrage mit der Autorisation Backend immer übergeben. In dieser Etappe ist die Notiz "accel_st" "AUTH" gleich.

Wenn die vorhergehenden Prüfungen vorbeigekommen sind, so wird es angenommen, dass die Antwort auf die Abfrage verschlüsselt im Prinzip sein kann.

Weiter, wenn die Direktive AccelInvalidate aktiv ist, so wird das Vorhandensein der Zeile der Erneuerung Ende URL'а geprüft. Wenn sie ist, wird die Abfrage Backend übergeben und wird die Notiz "accel_st" "INVL" gleich sein.
Wenn die Direktive AccelIgnoreNoCache nicht aktiv ist, so werden die Kopfteile "Pragma geprüft: no-cache", "Cache-Control: no-cache" und "Cache-Control: max-age=0". Bei Vorhandensein von jedem der aufgezählten Kopfteile wird die Abfrage Backend übergeben und die Notiz "accel_st" wird "PGNC" gleich sein.
Dann wird die Antwort im Cache gesucht. Wenn er nicht gefunden ist, so werden die Prüfungen busy lock'ов, der Zahl der Verbinden mit Backend und der Zahl der wartenden Prozesse. Wenn die Antwort von anderem Prozess nicht bearbeitet wird, hat die Zahl der Verbinden oder der wartenden Prozesse Maximum nicht erreicht, so wird die Abfrage Backend übergeben und wird die Notiz "accel_st" "MISS" gleich sein.
Wenn die Antwort auch die Direktive AccelIgnoreNoCache ist ist nicht aktiv, so wird der Kopfteil "Cache-Control geprüft: max-age = <die Zahl>", aufgebend die maximale Speicherzeit der Antwort im Cache. Wenn die Antwort bewahrt wird ist als die abgefragte Uhrzeit länger, so wird nach der Prüfung busy lock'ов, der Zahl der Verbinden mit Backend und der Zahl der wartenden Prozesse die Abfrage Backend übergeben und wird die Notiz "accel_st" "AGED" gleich sein.
Wenn die Direktive AccelRevalidateUser aktiv ist, so wird die Abfrage Backend übergeben und wird die Notiz "accel_st" "RVUS" gleich sein.
Danach wird geprüft, ob die Antwort veraltet ist. Wenn, so nach der Prüfung busy lock'ов veraltet ist, wird die Zahlen der Verbinden mit Backend und der Zahl der wartenden Prozesse die Abfrage Backend übergeben und wird die Notiz "accel_st" "EXPR" gleich sein.
Und endlich, wenn die Antwort nicht veraltet ist oder das Verbinden mit Backend wird verboten, so kehrt er dem Klienten zurück und die Notiz "accel_st" wird "HIT" gleich sein.

Wenn die Antwort auf die Abfrage im Cache ist, aber schon veraltet es, so wird in die Abfrage zu Backend der Kopfteil "If-Modified-Since" ergänzt. Bei dem Erhalten der Antwort mit dem Code 304 (HTTP_NOT_MODIFIED) wird der Inhalt des Caches entsprechend den bekommenen Kopfteilen erneuert und dem Klienten wird die Antwort aus dem Cache übergeben.

Wenn die Antwort auf die Abfrage des Klienten nicht voll, zum Beispiel, sein kann wenn es in der Abfrage des Klienten die Kopfteile "If-Modified-Since", "If-Unmodified-Since", "If-Match" gibt, wird "If-None-Match" oder der Teil der Antwort (byte-range) abgefragt, und gibt es keine Antwort im Cache, aber kann er verschlüsselt im Prinzip sein, so entfernen sich diese Kopfteile bei der Abfrage zu Backend, um die volle Antwort und, möglich zu bekommen, es im Cache zu speichern. Dem Klienten kehrt der davon abgefragte Teil der Antwort (byte-range zurück) oder es kehrt die Antwort mit dem Code 304 (HTTP_NOT_MODIFIED) bei der Beachtung der Bedingungen, die in den Kopfteilen als "If-Modified-Since" angegeben sind zurück.

Selb verhält sich zur Abfrage HEAD. Wenn es keine Antwort im Cache, aber er im Prinzip cached gibt, so wird zu Backend GET Anfrage gerichtet, um die volle Antwort und, möglich wieder zu bekommen, es im Cache zu speichern. Dem Klienten kehrt nur der Kopfteil der Antwort zurück.

Busy lock

Bevor die Abfrage zu Backend weggeht, werden vorläufig busy lock, die Zahl der Verbinden mit Backend und die Zahl der wartenden Prozesse geprüft. Busy lock lässt zu, Backend cached die Abfrage nicht zu übergeben, falls genau solche Abfrage Backend schon bearbeitet wird. Busy lock wird von der Direktive AccelBusyLock festgestellt und garantiert, dass im Laufe von der aufgegebenen Uhrzeit vom Anfang des Ausführens der Abfrage zu Backend nur einer der Prozesse Apache diese Abfrage Backend übergeben wird. Wenn es im Cache die veraltende Antwort auf diese Abfrage gibt, aber ist er nicht mehr als auf die Uhrzeit veraltet, die von der Direktive AccelMaxStale aufgegeben ist, so werden alle übrigen Prozesse diese veraltende Antwort aus dem Cache zurückgeben. Andernfalls werden alle übrigen Prozesse, die solche Abfrage erfüllen, oder die Antwort warten, die den ersten Prozess bekommen wird, oder, auf den Ablauf busy lock'а, bestimmt von diesem Prozess zu warten. AccelBusyLock lässt zu, drei Werte busy lock'а festzustellen. Erster wird verwendet falls es keine Antwort im Cache gibt oder er ist mehr als auf die Uhrzeit veraltet, die von der Direktive AccelMaxStale aufgegeben ist. Zweiter wird verwendet falls die Antwort im Cache weniger als auf die Uhrzeit veraltet ist, die von der vorhergehenden Direktive aufgegeben ist. Den zweiten Wert ist es empfehlenswert, grösser, als erstes festzustellen. Dritter gibt die maximale Uhrzeit auf, die der Prozess in busy lock'е durchführen kann, da der Prozess konsequent auf die Befreiung einige busy lock'ов warten kann. Wir werden vermuten, dass gleichzeitig drei identische Abfragen gekommen sind und bei auf sind solche Parameter aufgegeben:

AccelBusyLock 20 25 30

Die erste Abfrage wird Backend übergeben sein. Andere warten zwei in busy lock'е. Wir werden vermuten, dass nach Ablauf von 20 Sekunden die Antwort von Backend nicht bekommen ist. Die zweite Abfrage wird Backend übergeben, dritte setzt fort, auf zwei ersten Antworten zu warten. Aber die maximale summarische Uhrzeit seiner Erwartung kann mehr 30 Sekunden, deshalb nicht sein wenn im Laufe von dieser Uhrzeit Backend, so nicht antworten wird wird die dritte Abfrage Backend übergeben sein unter der Bedingung, dass die Zahl der Verbinden mit Backend Maximum nicht erreicht hat.

Wir werden zulassen, bei uns sind solche Parameter aufgegeben:

AccelBusyLock 10 15 
AccelMaxStale 60

Wir werden die Logik der Arbeit busy lock'ов vom folgenden Beispiel exemplifizieren:

00:00. Es ist die Abfrage gekommen, keine Antwort auf den im Cache gibt es. Da in diesen Moment niemand solche Abfrage bearbeitet, so übergibt der Prozess die Abfrage Backend, vorläufig busy lock, der um 00:10 (der erste Wert AccelBusyLock gleich 10 Sekunden ablaufen wird festgestellt).
00:04. Es ist die zweite Abfrage gekommen. Da erster, so der Prozess noch bearbeitet wird, der die zweite Abfrage übernahm, wartet auf die Befreiung busy lock'а oder des Erscheinens der Antwort im Cache.
00:07. Es ist die dritte Abfrage gekommen. Da erster, so der Prozess immer noch bearbeitet wird, der die dritte Abfrage übernahm, wartet auf die Befreiung busy lock'а oder des Erscheinens der Antwort im Cache ebenso, wie auch den zweiten Prozess.
00:10. Da busy lock des ersten Prozesses abgelaufen ist, werden wir einer der Prozesse, zulassen, stellt dritter noch einen busy lock fest und übergibt die Abfrage Backend. Der zweite Prozess, wie auch früher, wartet auf die Befreiung schon neu busy lock'а oder des Erscheinens der Antwort im Cache. Man muss bemerken, dass nach den Ablauf busy lock'а nur ein Prozess aus den Wartenden noch einen busy lock feststellen kann.
00:12. Der erste Prozess hat die Antwort bekommen und hat es ins Cache gespeichert. Die Notiz "accel" für diese Abfrage wird "MISS/-/0/- 200/CTL/300 12 gleich sein...", dass bedeutet - die Antwort war im Cache nicht und er war von Backend ohne Erwartung in busy lock'е bekommen, die Code die Antwort Backend - 200 (HTTP_OK), die Antwort cached, die Uhrzeit Caching werden im Kopfteil "Cache-Control" angewiesen und ist 300 Sekunden ("CTL/300") gleich, Backend bearbeitete die Abfrage 12 Sekunden. Von da an, im Laufe von der Sekunde wird der zweite Prozess die Antwort im Cache sehen und wird beginnen, seinem Klienten zurückzugeben. Die Notiz "accel" für die zweite Abfrage wird "HIT/-/8/- gleich sein HIT/-/-...", dass bedeutet - der Prozess hat die Antwort aus dem Cache bekommen, 8 Sekunden (00:04-00:12) in busy lock'е erwartet.
00:23. Der dritte Prozess hat die Antwort bekommen und hat die Antwort im Cache erneuert. Die Notiz "accel" wird "MISS/-/3/- 200/CTL/300 13 gleich sein...", dass bedeutet - in busy lock'е auf 3 Sekunden (00:07-00:10) gewartet, hat der Prozess die Abfrage Backend übergeben, die Code die Antwort Backend - 200 (HTTP_OK), die Antwort cached, die Uhrzeit Caching werden im Kopfteil "Cache-Control" angewiesen und ist 300 Sekunden gleich, Backend bearbeitete die Abfrage 13 Sekunden. Man muss bemerken, dass die Antwort im Cache und erneuert werden von einigen Prozessen gleichzeitig zurückgegeben werden kann.
03:10. Es ist die vierte Abfrage gekommen. Da die Antwort noch nicht veraltet, so wird er aus dem Cache zurückgegeben. Die Notiz "accel" wird "gleich sein HIT/-/-/- HIT/-/-...", dass bedeutet - die Antwort war aus dem Cache bekommen.
06:16. Es ist die fünfte Abfrage gekommen. Da die Abfrage um 05:23 veraltet ist und bearbeitet in diesen Moment niemand solche Abfrage, so übergibt der Prozess die Abfrage Backend, vorläufig busy lock festgestellt.
06:20. Es ist die sechste Abfrage gekommen. Die Antwort auf ihn schon veraltet, aber noch nicht sehr alt (AccelMaxStale ist 60 Sekunden gleich, das heißt, die Antwort wird ganz veraltend um 06:23). Deshalb, da solche Abfrage auch seiner busy lock schon bearbeitet wird wird um 06:31 (der zweite Wert AccelBusyLock gleich 15 Sekunden) ablaufen, so übernimmt die Antwort aus dem Cache und die Notiz "accel" wird "HIT/57/0/U gleich sein HIT/-/-...", dass bedeutet - obwohl die Antwort auf 57 Sekunden (05:23-06:20), aber veraltet ist da zu jenem Moment die Abfrage ("U") schon erneuert wurde, so war die Antwort aus dem Cache ohne Erwartung in busy lock'е bekommen.
06:24. Es ist die siebente Abfrage gekommen. Die Antwort auf ihn schon ganz veraltet, aber da solche Abfrage auch seiner busy lock für die siebente Abfrage bearbeitet wird um 06:26 (für die Antworten veraltend grösser, als auf die Uhrzeit verwendet wird, die von der Direktive AccelMaxStale aufgegeben ist, der erste Wert AccelBusyLock, für unseren Fall den gleichen 10 Sekunden ablaufen wird ), so wartet der Prozess auf die Befreiung busy lock'а oder des Erscheinens der Antwort im Cache.
06:25. Der Prozess, der mit der fünften Abfrage arbeitet, hat die Antwort von Backend bekommen und hat es im Cache erneuert. Die Notiz "accel" wird "EXPR/53/0/- 200/CTL/300 13 gleich sein...", dass bedeutet - die Antwort ist auf 53 Sekunden (05:23-06:16) veraltet und er war von Backend ohne Erwartung in busy lock'е bekommen, die Code die Antwort Backend - 200 (HTTP_OK), die Antwort cached, die Uhrzeit Caching werden im Kopfteil "Cache-Control" angewiesen und ist 300 Sekunden gleich, Backend bearbeitete die Abfrage 13 Sekunden. Von da an, im Laufe von der Sekunde wird der Prozess, der mit der siebenten Abfrage arbeitet, die Antwort im Cache sehen und wird beginnen, seinem Klienten zurückzugeben. Die Notiz "accel" wird "HIT/61/1/N gleich sein HIT/-/-...", dass bedeutet - die Antwort ist auf 61 Sekunde (05:23-06:24) veraltet, und, 1 Sekunde (06:24-06:25) in busy lock'е erwartet, hat der Prozess die erneuerte Antwort aus dem Cache bekommen.

Die Beschränkung der Zahl der Abfragen

Busy lock sind für die Verkleinerung der Belastung auf Backend vorbestimmt. Es sind die Situationen gleichzeitig möglich, wenn Backend mit der Bearbeitung der bekommenen Abfragen nicht zurechtkommt, und die neuen Abfragen setzen fort, zu handeln. In diesem Fall werden die Prozesse Frontend, die bearbeitenden neuen Abfragen, oder auf die Antwort von Backend warten, zu ihm angeschaltet geworden, oder, zu versuchen, sich mit Backend zu verbinden, oder, in busy lock'е zu warten. Die Zahl der Prozesse Frontend kann das Maximum und dabei erreichen wenn sich Frontend außer Proxyseiner Backend auch mit anderen Abfragen beschäftigen soll, so werden diese Abfragen nicht bedient werden. So kann ein überlastet Backend unzugänglich die übrigen Ressourcen, bedient es Frontendом machen. Für die Vermeidung der ähnlichen Situationen in der Direktive AccelPass kann man die Fahnen MC und MW, zulassend bezeichnen, entsprechend die Zahl der Verbinden mit Backend und die Zahl der Prozesse, wartend diesen Backend in busy lock'е zu beschränken. Wenn Maximum nach einem der Parameter erreichen werden und gibt es im Cache die Antwort auf die Abfrage, so kehrt er dem Klienten immer zurück, unabhängig davon, inwiefern er veraltet ist. Wenn es keine Antwort im Cache gibt, so kehrt der Fehler 503 (HTTP_SERVICE_UNAVAILABLE zurück). Außerdem kann man solche Fahnen in der Direktive RewriteRule des Bausteines mod_rewrite zusammen mit der Fahne P bezeichnen, wenn nur das Modul mod_accel konfigurieren mit dem Parameter nicht war --without-mod_rewrite.

Die primitive Zuordnung der Belastung und Fehler Resistanz

Die primitive Zuordnung der Belastung und Fehler Resistanz kann man aufgrund DNS realisieren, wenn ein Name einigen IP-Adressen entspricht. Man muss bemerken, dass der Hinweis der alternativen Adressen in der Datei /etc/hosts Dazu wird nicht herankommen - man muss die Abfragen zum DNS-Server machen. Außerdem muss man die Fahne NR in der Direktive AccelPass für das Verbot der Bestimmung der IP-Adresse Backend auf dem Start bezeichnen. In diesem Fall wird Frontend die IP-Adressen Backendов bei jeder Behandlung bestimmen und, sich mit einem von einigen Backendов zu verbinden. Für die Erzeugung des Schlüssels im Cache wird URL in jener Art verwendet, in welcher er nach dem Ersetzen des lokalen Präfixes auf проксируемый ohne Bestimmung der IP-Adressen erhalten wird, deshalb vom Standpunkt mod_accel sind die Antworten von verschiedenen Backendов auf eine und derselbe Abfrage äquivalent und die ins Cache geratende Antwort eines Servers wird den Klienten zurückgegeben werden, bis veralten wird. Selb verhält sich zu busy lock'ам und den Beschränkungen auf die Verbinden, das heißt, das Team Backendов wird wie ein Backend betrachtet.

Primitiv Fehler Resistanz kann man realisieren, den kleinen Wert dem zweiten Parameter der Direktive AccelTimeout aufgegeben. Standardmäßig ist time out auf das Verbinden ungefähr 75 Sekunden gleich. Bei der normalen Arbeit wird das Verbinden für die Anteile der Sekunde in der Regel festgestellt. Wenn diesen time out auf etwas Sekunden festzustellen, so wird nach sein Ablauf mod_accel versuchen, zum Folgenden Backend angeschaltet zu werden. Jedoch kann nicht immer Backend das Ergebnis zurückgeben, selbst wenn Frontend der Smog mit ihm verbinden, sich. Deshalb nach den Ablauf time outs, aufgegeben in den Parametern der Direktive AccelTimeout, beim Abhang des Verbindens mit Backend oder beim Erhalten der Antwort mit dem Ergebnis 5XX mod_accel schließt das Verbinden und geht zum Folgenden Backend über. Mit Hilfe der Direktive AccelRetry5XX off kann man verbieten, zu versuchen, sich mit anderem Backend beim Erhalten der Antwort mit dem Ergebnis 5XX zu verbinden. Die Ergebnisse der Versuche der Verbinden werden in den Notizen fixiert, das heißt, sie kann man im Hohlweg sehen, aber sie werden für die Auswahl Backend bei den folgenden Abfragen auf keine Weise verwendet.

Welche Antworten Caching

Die Lösung von der Band, Cache die bekommene Antwort oder nicht, nimmt sich in der folgenden Ordnung vor:

Vor allem, die Notiz "accel_st" soll "PASS", "NTNC" und "AUTH nicht" gleich sein. Außerdem soll die Antwort von Backend vollständig bekommen sein und, die Kennzahl 200 (HTTP_OK), 301 (HTTP_MOVED_PERMANENTLY) oder 302 (HTTP_MOVED_TEMPORARILY) haben.
Wenn die Notiz "accel_st" "NTNC" gleich ist, so wird die Notiz "accel_bc" "NNC" gleich sein. Die bekommene Antwort nicht cached, sondern auch die alte Antwort im Cache entfernt sich nicht.
Dann wird der spezielle Kopfteil "X-Accel-Expires geprüft: <die Zahl>", in dem es angewiesen wird, durch wieviel der Sekunden wird die Antwort veralten. Die Sekunden werden von der Uhrzeit abgezählt, die im Kopfteil "Date" angegeben ist. Obwohl einige Divergenz in der Uhrzeit zwischen Frontendом und Backend nichtsdestoweniger der Kopfteil "X-Accel-Expires dabei möglich ist: 0" immer verbietet Cache, unabhängig von der Divergenz in der Uhrzeit. Im Unterschied zu den Kopfteilen "Cache-Control" und "Expires", "X-Accel-Expires" dem Klienten wird nicht übergeben. Wenn die Lösung über Caching aufgrund dieses Kopfteiles, so wird die Notiz "accel_bc" "XAE" gleich sein, und die Notiz "accel_bct" - der Uhrzeit gefasst wird, die in diesem Kopfteil angegeben ist.
Wenn der vorhergehende Kopfteil fehlt, so wird der Kopfteil "Cache-Control" geprüft, in dem zwei Werte - "no-cache" und "max-age = <die Zahl> berücksichtigt werden". Wie auch für den vorhergehenden Fall, "max-age=0" hängt von der Divergenz in der Uhrzeit nicht ab. Die Prüfung dieses Kopfteiles kann man mit Hilfe der Direktive AccelIgnoreExpires on verbieten. Wenn die Lösung über Caching aufgrund dieses Kopfteiles, so wird die Notiz "accel_bc" "CTL" gleich sein, und die Notiz "accel_bct" - der Uhrzeit gefasst wird, die in diesem Kopfteil angegeben ist. Wenn der Kopfteil "no-cache" bedeutet, so wird die Notiz "accel_bct" "N" gleich sein.
Dann wird der Kopfteil "Expires" geprüft. Falls die Uhrzeit, die im Kopfteil "Date" angegeben ist, oder gleich die Uhrzeit, die im Kopfteil "Expires" angegeben ist, die Antwort nicht cached ist weniger. Die Prüfung dieses Kopfteiles kann man mit Hilfe der Direktive AccelIgnoreExpires on verbieten. Wenn die Lösung über Caching aufgrund dieses Kopfteiles, so wird die Notiz "accel_bc" "EXP" gleich sein, und die Notiz "accel_bct" - dem Unterschied in der Uhrzeit, angegeben im Kopfteil "Expires" und "Date" gefasst wird.
Wenn die vorhergehenden Prüfungen wozu auch die Codas der Antwort nicht gebracht haben ist 302 (HTTP_MOVED_TEMPORARILY), so die Antwort nicht cached gleich. Wenn die Code der Antwort 301 (HTTP_MOVED_PERMANENTLY), so wird die Antwort cached auf die Uhrzeit, die von der Direktive AccelCleanLastAccessed aufgegeben ist, die Notiz "accel_bc" "MVD" gleich sein, und die Notiz "accel_bct" - der Uhrzeit Caching gleich sind. Wenn die Code der Antwort 200 (HTTP_OK) gleich sind, so werden die folgenden Prüfungen erfüllt:
Wenn die Direktive AccelLastModifiedFactor angegeben ist, und gibt es in der Antwort den Kopfteil "Last-Modified", so wird die Uhrzeit Einstellung nach solcher Formel ausgerechnet:
```
Expires = (Date - LastModified) * AccelLastModifiedFactor / 100 
```
Die Uhrzeit Einstellung wird von der laufenden Uhrzeit auf Frontend abgezählt. Wenn die Lösung über Caching in dieser Etappe, so wird die Notiz "accel_bc" "LMF" gleich sein, und die Notiz "accel_bct" - der ausgerechneten Uhrzeit gefasst wird.
Endlich, die Uhrzeit Einstellung kann man von der Direktive AccelDefaultExpire, abgezählt von der laufenden Uhrzeit auf Frontend bezeichnen. In diesem Fall wird die Notiz "accel_bc" "ADE", und die Notiz "accel_bct" - der angegebenen Uhrzeit gleich sein.
Wenn es daraufhin misslang die Uhrzeit Einstellung zu bestimmen, so werden die Antwort nicht cached und die Notizen "accel_bc" und "accel_bct" gleich sein, "-".

Die Notizen, mit deren Hilfe man den Baustein verwalten kann

Seit der Version 1.0.2, das Verhalten des Bausteines mod_accel kann man mit Hilfe der Notiz "accel_nocache" verwalten. Wenn diese Notiz auszustellen, so wird mod_accel immer zu Backend Anfrage richten, das Cache nicht prüfend. Die bekommene Antwort niemals cached, und wenn im Cache die Antwort, so entfernt er sich nicht schon ist. Seit der Version 1.0.24, selb kann man mit Hilfe der variabelen "ACCEL_NOCACHE - Umgebung machen.

Seit der Version 1.0.18, das Modul mod_accel in der Notiz "accel_request_body" kann den Körper der Abfrage übergeben.

Seit der Version 1.0.18, das Modul mod_accel in der Notiz "accel_rewrite_response" kann die Adresse Prozedur für die Bearbeitung der Antwort Backend übergeben. Die Prozedur soll den folgenden Prototyp haben:

int rewrite_handler (accel_rec *a);

Sie meldet sich nach dem Erhalten des Kopfteiles und, möglich, des ersten Teiles der Antwort von Backend. Wenn man die Antwort Backend unveränderlich zurückgeben muss, so soll die Prozedur den Wert DECLINED zurückgeben und wird mod_accel die Bearbeitung der Abfrage fortsetzen. Bei der Rückgabe jedes Wertes wird es angenommen, dass die Prozedur selbst die Abfrage vollständig bearbeitet hat.

Wie mit cookie zu arbeiten

Wenn die Antworten verschlüsselt, so entfernt sich der Kopfteil "Cookie" aus der Abfrage zu Backend, und den Kopfteil "Set-Cookie" - aus der Antwort Backend sein können, da cookie den Inhalt der Antwort beeinflussen kann. Jedoch wenn Sie überzeugt sind, dass cookie den Inhalt der Antworten auf keine Weise beeinflussen, so können Sie die Direktive AccelPassCookie on feststellen. Wenn Sie überzeugt sind, dass der Kopfteil "Set-Cookie" den Sinn Cache hat, so können Sie die Direktive AccelCacheSetCookie on feststellen. Außerdem ist es Cache die Antwort je nach cookie mit Hilfe der Direktive AccelCacheCookie möglich. Endlich, wenn die Autorisation mit der Hilfe cookie gemacht ist, so kann man die Direktive AccelRevalidateUser verwenden.

Dass man in den Hohlweg speichern kann

Die Tätigkeit mod_accel kann man mit Hilfe der Notizen analysieren, die man in den Hohlweg in der Art % {accel} x speichern kann:

accel_r — Die erste Zeile der Abfrage, die Backend, zum Beispiel, übergeben ist "GET http://127.0.0.1/test/ HTTP/1.0". Die Adresse Backend in dieser Notiz ist in der numerischen Art immer vorgestellt.
accel — die Notiz, in der alle untengenannten Notizen, ihr Format solcher vereinigt sind: "accel_st/accel_et/accel_lt/accel_ls accel_bs/accel_bc/accel_bct accel_bt accel_bnr/accel_bfr/accel_br accel_fl"
accel_st — Der Zustand der Abfrage. Kann die Werte "PASS", "NTNC", "AUTH", "INVL", "PGNC", "MISS", "AGED", "EXPR" übernehmen, "RVUS" und "HIT" in der Ordnung, die im Abschnitt beschrieben ist "Wenn kann die Antwort aus dem Cache" und den Wert "RMVD" bekommen sein, wenn die Datei aus dem Cache mit Hilfe des Managers des Caches gelöscht war.
accel_et — Die Uhrzeit in den Sekunden, vorführend inwiefern ist die im Cache bewahrte Antwort auf die Abfrage veraltet.
accel_lt — Die Uhrzeit in den Sekunden, im Laufe von denen der Prozess in busy lock'е war.
accel_ls — Der Zustand busy lock'а, der Beschränkungen zum Zeitpunkt der Rückerstattung der Antwort auf die Abfrage und die Kennziffer der Frische der Antwort. Kann eine Kombination solcher Werte - "U", "C", "W" und "N" sein. Das Symbol "U" bedeutet, dass die Abfrage von anderem Prozess schon erneuert wird. Dieser Wert erscheint in der Kombination mit der Notiz accel_st, gleich "HIT", zum Beispiel, "HIT/5/0/U" immer, das heißt, die Antwort auf die Abfrage ist im Cache, er ist auf 5 Sekunden, aber veraltet da es AccelMaxStale weniger ist und die Antwort wird schon erneuert, so haben dem Klienten diese veraltende Antwort zurückgegeben. Das Symbol "C" bedeutet, dass die Zahl der Verbinden mit Backend den Wert MC erreicht hat, und das Symbol "W" - dass hat die Zahl der Prozesse, die in busy lock'ах der Antwort von Backend warten den Wert MW erreicht. Die Werte "C" und "W" erscheint in der Kombination mit der Notiz accel_st, gleich "HIT" oder "MISS", zum Beispiel, "HIT/10/0/C" (im Cache gibt es die auf 10 Sekunden veraltende Antwort und da die Zahl der Verbinden Maximum erreicht hat, so haben dem Klienten diese veraltende Antwort zurückgegeben) und "HIT/15/5/CW" (im Cache es die auf 15 Sekunden veraltende Antwort gibt, aber diese Antwort wird schon erneuert, der Prozess hat in busy lock'е auf 5 Sekunden gewartet und hat die veraltende Antwort zurückgegeben, da zu dieser Uhrzeit die Zahl der Verbinden und der wartenden Prozesse Maximum erreicht hat). Das Symbol "N" bedeutet, dass nach der Erwartung in busy lock'е der Prozess die erneuerte Abfrage bekommen hat. Zum Beispiel, dieses Symbol im Beispiel, das vorhergehenden ähnlich ist - "HIT/15/5/CWN", bedeutet, dass dem Klienten die erneuerte Abfrage zurückgegeben haben.
accel_bs — Die Code der Antwort Backend, wenn die Antwort aus dem Cache bekommen war, so wird diese Notiz "HIT" gleich sein.
accel_bc — Aufgrund es wessen war es wird die Lösung über Caching der Antwort gefasst. Kann die Werte - "NNC", "XAE", "CTL", "EXP", "MVD", "LMF" und "ADE" in der Ordnung, die im Abschnitt beschrieben ist "Welche Antworten Caching" übernehmen.
accel_bct — Die Uhrzeit Caching in den Sekunden.
accel_bt — Die Uhrzeit der Bearbeitung der Abfrage Backend in den Sekunden.
accel_bnr - Die Zahl der Operationen der Lektüre der Antwort Backend. Kann auf die Einheit grösser realer Zahl sein, unter anderem wird für die kleinen Antworten, deren Umfang es mehreren Rahmen ethernet'а die reale Zahl der Lektüren gibt 2 (die ganze Antwort nimmt sich einer Lektüre vor, bei der zweiten Lektüre wird die Dateiende bekommen sein), und in der Notiz wird 3 gespeichert sein. Nichtsdestoweniger, diese Notiz spiegelt die reale Lage der Sachen im Falle der großen Antwort und einiger Latentzeit, die in der Direktive AccelWaitBeforeBodyRead aufgegeben ist wider.
accel_bfr - Der summarische Umfang des Kopfteiles der Antwort und des Körperteiles der Antwort, der für die erste Lektüre nach der Latentzeit bekommen ist, aufgegeben in der Direktive AccelWaitBeforeBodyRead.
accel_br - Die Gesamtgröße der Antwort, die von Backend in den Bytes bekommen ist. Schließt den Kopfteil der Antwort ein.
accel_fl - Die Fahnen der Antwort. Kann eine Kombination der Werte "R", "Q" und "F" sein. "R" bezeichnet, dass die Antwort vom Baustein mod_randban, "Q" - den Baustein mod_quoted, und "F" - den Baustein mod_freeze bearbeitet war.

Das Reinigen des Caches

Das Reinigen des Caches wird vom abgesonderten Prozess - den Kassierer des Mülls, der vom bevorzugten Server Apache ausgeführt wird und von ihm wird kontrolliert. Nach dem Start wird der Kassierer des Mülls auf den Benutzer und das Team, angegeben in den Direktiven User und Group umgeschaltet. Die meiste Zeit schläft dieser Prozess, nur für das Reinigen des Caches aufwachend. Es kann man von anderen Prozessen Apache mit Hilfe der Mannschaft unterscheiden ps - Im Namen des Prozesses ist die Zeile "garbage collector" anwesend. Die Direktive AccelClean gibt auf, wie man das Cache oft reinigen muss. Reinigen es kann einmal pro Tage in die aufgegebene Uhrzeit oder durch ein bestimmtes Intervall der Uhrzeit, das von der Uhrzeit des Startens des Prozesses oder von der Uhrzeit des Herunterfahrens des letzten Reinigens des Caches abgezählt wird. Man muss bemerken, dass beim Start der Kassierer nicht das Reinigen des Caches sofort beginnt, und wartet eine Minute, da in der Regel während des Restartes Apache die Belastung auf den Server zunimmt. Außerdem schläft während des Reinigens der Kassierer auf eine Sekunde nach der Prüfung jede 1000 Dateien ein. Unter den Dateien werden nicht nur die gewöhnlichen Dateien des Caches, aber die Dateien der Kataloge in diesem Fall gemeint, weil beim Job der Niveaus des Caches "1 2", die Zahl der Dateien der Kataloge 4096 wird. Wenn man das Cache eilig reinigen muss, den Ablauf des Intervalls nicht erwartend, kann man einfach so den Prozess von der Mannschaft beenden kill Und Apache wird des Kassierers wieder neustarten.

Der Kassierer löscht die Dateien im Cache, die mehr einer Stunde rückwärts veraltet sind oder zu ihm behandelten im Laufe von der Uhrzeit nicht, die von der Direktive AccelCleanLastAccessed nicht aufgegeben ist folgt auf den Umfang des Caches, da es den Sinn für den Fall Proxydes Internets, und nicht des konkreten Standortes hat, dessen Umfang mehr oder weniger bekannt ist. Außerdem löscht der Kassierer die temporären Dateien, an die sich mehr der Stunde und die Kataloge und die Dateien des Caches, die nach der Veränderung der Struktur des Caches blieben nicht behandelten.

Die Direktiven

Die Direktive AccelAddVia

syntax: AccelAddVia on|off
default: AccelAddVia off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht in den Kopfteil "Via" in der Abfrage, die Backend übergeben wird, die Zeile über Frontend zu ergänzen. Die ergänzte Zeile sieht der Folgende - "' die Version des Protokolles der Abfrage ' ' der Domänename Frontend ' (' die Version mod_accel ')", zum Beispiel, "1.1 www.domain.com (mod_accel/1.0.34)" aus.

Die Direktive AccelAddXForwardedFor

syntax: AccelAddXForwardedFor on|off
default: AccelAddXForwardedFor off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht in den Kopfteil "X-Forwarded-For" in der Abfrage, die Backend übergeben wird, die IP-Adresse zu ergänzen, von der die Abfrage zu Frontend gemacht war.

Die Direktive AccelBkRcvBuffSize

syntax: AccelBkRcvBuffSize der Umfang
default: AccelBkRcvBuffSize 16
context: server config, virtual host, location, files

Die Direktive gibt den Umfang des Puffers in den Kilobytes für die Aufnahme der Antwort von Backend auf. Wenn der Umfang der Antwort den Umfang des Puffers übertritt, so wird der Inhalt des Puffers in die temporäre Datei gespeichert.

Die Direktive AccelBkRcvSockBuffSize

syntax: AccelBkRcvSockBuffSize der Umfang
default: AccelBkRcvSockBuffSize 0
context: server config, virtual host, location, files

Die Direktive gibt den Umfang des TCP-Puffers des Kernes in den Kilobytes für die Aufnahme der Antwort von Backend auf. Der Umfang wird von der Systemanfrage setsockopt () mit dem Parameter SO_RCVBUF festgestellt. Wenn der Wert der Direktive gleich der Null, so meldet sich setsockopt () nicht und der Umfang des TCP-Puffers, der standardmäßig aufgegeben ist verwendet wird.

Die Direktive AccelBusyLock

syntax: AccelBusyLock "die Uhrzeit" ["die Uhrzeit" ["die Uhrzeit"]]
default: AccelBusyLock 0 0 AccelTimeout
context: server config, virtual host, location, files

Die Direktive gibt drei Werte busy lock'ов auf. Erster wird verwendet falls es keine Antwort im Cache gibt oder er ist mehr als auf die Uhrzeit veraltet, die von der Direktive AccelMaxStale aufgegeben ist. Zweiter wird verwendet falls die Antwort im Cache weniger als auf die Uhrzeit veraltet ist, die von der vorhergehenden Direktive aufgegeben ist. Dritter gibt die maximale Wartezeit in busy lock'Ñ auf. Detailliert ist die Logik der Arbeit busy lock'ов im Abschnitt "Busy lock" beschrieben. Beider Parameters kann man in Form von der Zeile, zum Beispiel, "2 minutes 30 seconds" oder in Form von einer Zahl aufgeben, die die Sekunden bedeutet.

Wenn der zweite Parameter nicht aufgegeben ist, so ist er erstem gleich.

Wenn der dritte Parameter nicht aufgegeben ist, so ist er dem ersten Parameter der Direktive AccelTimeout gleich. Der dritte Parameter ist in mod_accel, seit der Version 1.0.7 erschienen. In den früheren Versionen ist sein Wert dem ersten Parameter der Direktive AccelTimeout gleich.

Die Direktive AccelCacheCookie

syntax: AccelCacheCookie off|all | [!] die Zeile | [!] ~ [*] der regelmäßige Ausdruck
default: AccelCacheCookie off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.2 und mehr

Die Direktive gibt die Namen cookie auf, das bei Caching der Antwort des Servers berücksichtigt werden wird. Beim Job namens cookie kann man den Namen oder den regelmäßigen Ausdruck verwenden. Die Symbole "~ *" lassen zu, den regelmäßigen Ausdruck ohne Berücksichtigung des Registers der Symbole aufzugeben. Der Parameter "all" gibt allen cookie auf. Das Symbol "!" Lässt zu, den Teil cookie auszuschließen. Der Parameter "off" verbietet die Berücksichtigung cookie bei Caching. Wir werden vermuten, bei uns sind die Direktiven aufgegeben

AccelPass/test/http://backend/test/ 
AccelCacheCookie all! ~ ^id

In diesem Fall wird die Abfrage umgeleitet in die Abfrage "http://backend/test/one.html" "http://frontend/test/one.html". Schlüssel für die Suche im Cache ist das Ergebnis der chesch-Funktion md5, als deren Argument umgewandelt URL, für unseren Fall "http://backend/test/one.cgi?test=1" übergeben wird. Jedoch wenn der Benutzer cookie, zum Beispiel, "userid=12345 übergeben hat; pref=34; id=92", so wird ein Argument der chesch-Funktion md5 die Zeile "http://backend/test/one.cgi?test=1 pref=34; userid=12345". Bevor cookie zu URL ergänzt werden, werden sie nach dem Alphabet gesortiert. Wenn die Abfrage Backend übergeben sein wird, so werden zu ihm nur angegeben cookie - "pref=34 auch geraten; userid=12345".

Die Direktive berücksichtigt nur die Kopfteile "Cookie", kommend vom Klienten, und auf keine Weise beeinflusst den Kopfteil "Set-Cookie", übergeben von Backend.

In einem Block können etwas Direktiven AccelCacheCookie aufgegeben sein. Wenn im Block keine Direktive angegeben ist, so werden sie aus dem Vorhergehenden beerbt. Die Direktiven, die im angelegten Block nicht aufgegeben sind werden mit den Direktiven vereinigt, die im vorhergehenden Block aufgegeben sind. Der Parameter "off" macht aller übrigen Parameter rückgängig.

In der Version 1.0.2 sind nur zwei Arten der Parameter - "off" und die Zeile zulässig. Außerdem kann man in einer Direktive nur einen Parameter und die Namen cookie bezeichnen werden nicht gesortiert.

Die Direktive AccelCacheRoot

syntax: AccelCacheRoot der Pfad [1|2 [1|2 [1|2]]] [noauto]
default: AccelCacheRoot gibt es 1 2
context: server config

Die Direktive gibt den Katalog auf, in dem die Dateien des Caches und die temporären Dateien erstellt werden werden. Das ganze Cache soll sich auf einem Scheibenabschnitt, da die temporären Dateien ins Cache von der Operation link verschoben werden () befinden. Wenn nicht der absolute Pfad angegeben ist, so klärt sich der Katalog verhältnismäßig ServerRoot. Der Benutzer, von dessen Namen die Prozesse Apache arbeiten, sollen zur Lektüre und der Aufnahme in diesen Katalog sein rechtskräftig. Mit Hilfe dieser Direktive kann man die Verschachtelungsebene der Kataloge des Caches aufgeben. Standardmäßig werden 16 Kataloge des ersten Niveaus mit den Namen 0 verwendet. f, und 256 Kataloge des zweiten Niveaus mit den Namen 00. ff. Außerdem kann man dem Parameter "noauto" die automatische Bildung der Kataloge im Cache verbieten. Die automatische Bildung ist auf den stark beladenen Servern unerwünscht da bei jeder Bildung der neuen Datei des Caches wird ebenso ist der Versuch gemacht, alle Zwischenverzeichnisse zu erstellen. Für die Erhöhung der Produktivität ist es vor dem Starten Apache vorläufig empfehlenswert, alle Kataloge im Cache mit der Hilfe скрипта zu erstellen create_cache Und die automatische Bildung der Kataloge zu verbieten. Zum Beispiel, die Direktive

AccelCacheRoot/var/cache 1 1 noauto

Bezeichnet, dass sich das Cache im Katalog befindet /var/cache, Die Tiefe seiner Verschachtelung 2, die Namen der Kataloge beider Niveaus — 0. f, und diese Kataloge muss man automatisch im Laufe der Arbeit nicht erstellen.

Die Direktive AccelCacheSendSize

syntax: AccelCacheSendSize der Umfang
default: AccelCacheSendSize 8
context: server config, virtual host, location, files

Die Direktive bestimmt den Umfang des Puffers in den Kilobytes für die Sendung der Antwort aus dem Cache dem Klienten.

Die Direktive AccelCacheSetCookie

syntax: AccelCacheSetCookie on|off
default: AccelCacheSetCookie off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.23 und mehr

Die Direktive bestimmt, ob man ins Cache den Kopfteil "Set-Cookie" speichern kann.

Die Direktive AccelClean

syntax: AccelClean "die Uhrzeit"
default: AccelClean "1 hour"
context: server config

Die Direktive gibt die Uhrzeit oder das Intervall des Reinigens des Caches auf. Wenn in der Zeile das Symbol angegeben ist, so wird das Reinigen einmal pro Tage zur vorgeschriebenen Zeit, bedeutet anders der Wert das Intervall der Uhrzeit, nach dessen Ablauf das Reinigen des Caches erzeugt wird. Die Beispiele der Nutzung:

AccelClean "1 hour 30 minutes" 
AccelClean "5 hours"

Die Direktive AccelCleanLastAccessed

syntax: AccelCleanLastAccessed "die Uhrzeit"
default: AccelCleanLastAccessed "24 hours"
context: server config

Die Direktive bestimmt die maximale Uhrzeit des inaktiven Lebens der Datei im Cache. Wenn sich im Laufe von dieser Uhrzeit an die Datei nicht behandelten, so wird die Datei beim Reinigen des Caches gelöscht sein, selbst wenn er den Veraltenden nicht angenommen wird.

Die Direktive AccelContentTail

syntax: AccelContentTail die Länge
default: AccelContentTail 32
context: server config
compatibility: mod_accel 1.0.0-1.0.10

Die Direktive gibt den Umfang des Puffers, der von den Bausteinen verwendet wird, abändernd den Körper der Antwort auf.

Seit der Version 1.0.11, der Umfang des Puffers paßt automatisch an und die Direktive ist aufgehoben.

Die Direktive AccelDefaultExpire

syntax: AccelDefaultExpire "die Uhrzeit"
default: AccelDefaultExpire 0
context: server config, virtual host, location, files

Die Direktive gibt die Speicherzeit der Antwort auf, unter der Bedingung, dass diese Uhrzeit in anderen Weisen zu bestimmen es misslang.

Die Direktive AccelIgnoreAuth

syntax: AccelIgnoreAuth on|off
default: AccelIgnoreAuth off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.5 und mehr

Die Direktive bestimmt, oder nicht den Kopfteil "Authorization" in der Abfrage des Klienten zu ignorieren. Die Direktive kann man verwenden falls die Autorisation Frontendом durchgeführt wird und die Antwort Backend hängt vom Benutzer nicht ab und folglich aus dem Cache ausgegeben werden kann. Außerdem verwenden einige Programme stapel- скачивания, unter anderem FlashGet, den Kopfteil "Authorization" in der Rolle des Kopfteiles "Pragma: no-cache".

Die Direktive AccelIgnoreExpires

syntax: AccelIgnoreExpires on|off
default: AccelIgnoreExpires off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht die Kopfteile "Expires" und "Cache-Control", ausgestellt Backend zu ignorieren.

Die Direktive AccelIgnoreNoCache

syntax: AccelIgnoreNoCache on|off
default: AccelIgnoreNoCache off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht die Kopfteile "Pragma zu ignorieren: no-cache", "Cache-Control: no-cache" und "Cache-Control: max-age = <die Zahl>" in der Abfrage, dem übergebenen Klienten.

Auf den Druck auf Reload Netscape schickt den Kopfteil "Pragma: no-cache".
Netscape 6 und Mozilla auf den Druck auf Reload schickt zwei Kopfteile "Pragma: no-cache" und "Cache-Control: max-age=0", und auf den Druck Shift-Reload — "Pragma: no-cache" und "Cache-Control: no-cache".

Auf den Druck auf Refresh MSIE unter Windows bis zur Version 5.5 schickt den Kopfteil "Pragma einschließlich: no-cache" ist es nur, falls ihm angewiesen, den Proxy-Server zu verwenden. MSIE 5.5SP1 auf den Druck Control-Refresh immer schickt den Kopfteil "Pragma: no-cache" oder "Cache-Control: no-cache", je danach, welcher Version HTTP richtet er Anfrage. Die Versionen unter Macintosh schicken diesen Kopfteil überhaupt niemals nicht.

Auf den Druck auf Reload Konqueror schickt die Kopfteile "Pragma: no-cache" und "Cache-Control: no-cache".

Der Kopfteil "Cache-Control: max-age = <wird die Zahl>" Squid'ом gewöhnlich übergeben, in seiner Konfiguration protzt er mit der Direktive refresh_pattern und ist drei Tagen oder 259200 Sekunden standardmäßig gleich.

Die Direktive AccelInvalidate

syntax: AccelInvalidate строка|off
default: AccelInvalidate off
context: server config, virtual host, location, files

Die Direktive gibt die Zeile auf, bei deren Verbleib Ende URL der Inhalt des Caches für die gegebene Abfrage erneuert sein wird. Zum Beispiel, wenn die Direktive aufgegeben ist

AccelInvalidate _INVALIDATE

Jenes für die Erneuerung der Abfrage "http://frontend/test/one.hml?arg=1", muss man "http://frontend/test/one.hml?arg=1_INVALIDATE" Anfrage richten.

Die Direktive AccelLastModifiedFactor

syntax: AccelLastModifiedFactor die Zahl
default: AccelLastModifiedFactor 0
context: server config, virtual host, location, files

Die Direktive gibt die Zahl prozentual für die Bestimmung der Uhrzeit Caching aufgrund der laufenden Uhrzeit und des Kopfteiles "Last-Modified auf". Detailliert ist es im Abschnitt "Welche Antworten Caching" beschrieben.

Die Direktive AccelMaxStale

syntax: AccelMaxStale "die Uhrzeit"
default: AccelMaxStale 0
context: server config, virtual host, location, files

Die Direktive gibt die Uhrzeit auf, im Laufe von der die veraltende Antwort auf die Abfrage aus dem Cache zurückgegeben werden kann unter der Bedingung, dass einer der Prozesse Apache die erneuerte Antwort von Backend schon bekommt. Beider Parameters kann man in Form von der Zeile, zum Beispiel, "2 minutes" oder in Form von einer Zahl aufgeben, die die Sekunden bedeutet.

Die Direktive AccelModRewriteLocation

syntax: AccelModRewriteLocation on|off
default: AccelModRewriteLocation off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.30 und mehr

Die Direktive bezeichnet, ob mod_rewrite für das Umschreiben der Kopfteile "Location" und "Refresh" zu verwenden.

Die Direktive AccelNoCache

syntax: AccelNoCache on|off
default: AccelNoCache off
context: server config, virtual host, location, files

Die Direktive bezeichnet, ob die Antworten auf die Abfragen Cacheся können.

Die Direktive AccelNoPass

syntax: AccelNoPass das Präfix | ~ [*] der regelmäßige Ausdruck
default: nein
context: server config, virtual host

Diese Direktive bestimmt, welche Abfragen auf anderen Server nicht übergeben werden sollen, selbst wenn das Präfix der Abfrage mit einem der Präfixe, die in der Direktive AccelPass angegeben sind übereinstimmt. Es kann für den Fall nützlich sein, wenn der Standort von der Wurzel Backend erstellt wird, aber die statischen Dateien ist es besser, Frontendом zurückzugeben. Zum Beispiel, wenn solche Direktiven aufgegeben sind

AccelPass / http://backend/ 
AccelNoPass/images//download/~ *\.jpg $

Jenes werden die Abfragen, die auf anfangen "/images /" oder "/download /", Backend nicht übergeben werden. Außerdem werden die Abfragen zu Ende gehend auf ".jpg" oder ".JPG" auch Backend nicht übergeben werden. Die Symbole "~ *" vor dem regelmäßigen Ausdruck bezeichnen das Ignorieren des Registers. Man muss bemerken, dass die regelmäßigen Ausdrücke nur zu URI verwendet werden, werden zu PATH_INFO und den Argumenten der Abfrage nicht verwendet.

In einem Block können etwas Direktiven aufgegeben sein. Die Direktiven, die im angelegten Block aufgegeben sind werden mit den Direktiven vereinigt, die im vorhergehenden Block aufgegeben sind.

In mod_accel bis zur Version 1.0.3 darf man nicht die regelmäßigen Ausdrücke mit dem Ignorieren des Registers verwenden. Außerdem kann man in der Direktive nur einen Parameter verwenden und zwischen dem regelmäßigen Ausdruck und dem Symbol "~" kann das Leerzeichen stehen.

Die Direktive AccelPass

syntax: AccelPass das Präfix url [die Fahnen]
default: nein
context: server config, virtual host

Die Direktive bestimmt, welche Abfragen auf anderen Server übergeben werden sollen. Zum Beispiel, die Direktive

AccelPass/test/http://backend/test/

Wird umgeleitet alle Abfragen, die auf/test / anfangen, in die Abfragen "http://backend/test/". Zum Beispiel, die Abfrage wird umgeleitet in die Abfrage "http://backend/test/one.html" "http://frontend/test/one.html".

Wenn die Fahne PH, so gehört zur Abfrage immer der Kopfteil "Host", enthaltend den Namen und den Anschluß nicht bestimmt ist (wenn der Anschluß 80) des Servers, auf den umgeleitet die Abfrage nicht gleich ist.

Wenn die Antwort auf die Abfrage von sich redirect vorstellt, so wird der Kopfteil "Location", das heißt falls notwendig korrigiert, wenn der Kopfteil "Location" "http://backend/test/two.html" enthält, so wird er auf "http://frontend/test/two.html" geändert sein. In diesem Sinn die Direktive

AccelPass/test/http://backend/test/

Des Äquivalentes zwei Direktiven des Bausteines mod_proxy

ProxyPass/test/http://backend/test/ 
ProxyPassReverse/test/http://backend/test/

Außer dem Kopfteil "Location" wird der Kopfteil "Refresh" auch korrigiert.

Seit der Version 1.0.29, mod_accel korrigiert den Kopfteil "Destination" auch, wenn der Hostname in diesem Kopfteil mit dem Inhalt des Kopfteiles "Host", oder wenn URI nicht der Absolute übereinstimmt.

Seit der Version 1.0.11, als Antwort auf die Abfrage/test mod_accel gibt redirect auf URL mit beigefügt слэшом, das heißt, http://frontend/test/ zurück.

Die Direktiven werden zu ihrer Beschreibung durchgesehen, deshalb die mehr allgemeinen Präfixe muss man am Ende, zum Beispiel, verfügen:

AccelPass/test/http://backend1/test/ 
AccelPass / http://backend2/

In der Direktive kann man die folgenden Fahnen verwenden:

MC = <die Zahl> - Maximum Connect;
MW = <die Zahl> - Maximum Waiting;
MP = <H|P|L|Tтэг> - Maximum Part.
Die Fahne MP=Tтэг ist in mod_accel 1.0.6 erschienen.
Diese Fahnen beschränken die Zahl der Verbinden mit Backend (MC) und die Zahl der Prozesse wartend in busy lock'ах (MW). Wenn die Fahne MW nicht angegeben ist, so wird er dem Wert der Fahne MC gleich sein. Die Fahne MP bestimmt, welcher Teil URL im zweiten Parameter der Direktive für die Beschränkung verwendet wird. MP=L bedeutet allen URL, angegeben in der Direktive, MP=P - der Name Backend und den Anschluß und MP=H - nur den Namen Backend. Die letzte Variante wird standardmäßig verwendet. Außerdem erlaubt die Fahne MP=Tтэг biegsam, die Beschränkung anzupaßen. In der Qualität Tag kann ein beliebiges Wort ausgewählt sein. Wir betrachten eine Handlung der Fahnen auf dem Beispiel:
```
AccelPass/t1/http://backend:80/t1/ [MC=30, MW=40, MP=P] 
AccelPass/t2/http://backend:80/t2/ [MC=30, MW=40, MP=P] 

AccelPass/t3/http://backend:8080/t3/ [MC=20, MW=30, MP=H] 
AccelPass/t4/http://backend:8081/t4/ [MC=20, MW=30, MP=H] 

AccelPass/t5/http://backend:80/t5/ [MC=10, MW=10, MP=L] 

AccelPass/t6/http://backend:80/t6/ [MC=15, MW=15, MP=Tbk] 
AccelPass/t7/http://backend:80/t7/ [MC=15, MW=15, MP=Tbk] 
```
Zwei ersten Direktiven beschränken die Zahl der Verbinden mit dem Anschluß die 80 Server backend bis zu 30 und die Zahl Prozesse, die in busy lock'ах bis zu 40 warten. Jedoch verhält sich es zu URL nicht, anfangend auf "http://backend:80/t5/" - für sie ist die Zahl der Verbinden und der wartenden Prozesse 10 beschränkt. Selb verhält sich zu URL, anfangend auf "http://backend:80/t6/" und "http://backend:80/t7/" - für sie ist die summarische Zahl der Verbinden und der wartenden Prozesse 15 beschränkt. So die maximale summarische Zahl der Verbinden mit dem Anschluß die 80 Server backend - 55 (30, 10 und 15), die Zahl der wartenden Prozesse - 65 (40, 10 und 15). Gleichzeitig kann die Zahl der Verbinden mit den Anschlüßen die 8080 und 8081 Server backend in der Summe 20, und die Zahl der wartenden Prozesse - 30 nicht übertreten. Insgesamt kann mit dem Server backend nicht mehr 75 (30, 10, 15 und 20) der Verbinden, und die Zahl der wartenden dabei Prozesse - nicht mehr 95 (40, 10, 15 und 30) bestimmt sein.
In den Direktiven, die den Zugang auf eine und derselbe Ressource beschränken, es ist nötig die identischen Werte der Fahnen MC und MW zu verwenden. Das heißt, der Direktive
```
AccelPass/t3/http://backend:8080/t3/ [MC=10, MW=20, MP=H] 
AccelPass/t4/http://backend:8081/t4/ [MC=20, MW=30, MP=H] 
```
Werden, aber, möglich, nicht arbeiten so, wie Sie erwarten.
Die maximale Uhrzeit, im Laufe von der der Prozess verbunden mit dem Server oder wartend es angenommen wird, ist 1 Stunde gleich. Diese Beschränkung ist für die Situation notwendig, wenn der Prozess abnormal geendet ist ist nicht dazugekommen, den Zustand zu ändern.
NR - No Resolve.
Auf dem Start mod_accel bestimmt eine ip-Adresse jeder Backend und im Folgenden verwendet nur es. Die Fahne NR verbietet die Bestimmung der ip-Adressen auf dem Start. Diese Fahne muss man verwenden, wenn einem Domänenamen etwas Backendов entspricht und mit Hilfe des Servers DNS wird die primitive Zuordnung der Belastung und Fehler Resistanz realisiert.
PH - Preserve Host.
Diese Fahne ist in mod_accel 1.0.12 erschienen.
Die Fahne PH lässt zu, Backend den Hostnamen im Kopfteil "Host" den Unveränderlichen zu übergeben. Wenn in der Abfrage des Klienten dieser Kopfteil fehlt, so wird er Backend auch nicht übergeben. Die Nummer des Anschlußes ändert sich falls notwendig. Wenn zusammen mit der Fahne PH die Fahnen MC oder MW aufgegeben sind, aber ist die Fahne MP nicht aufgegeben, so wird für die Beschränkung der Zahl der Verbinden oder der wartenden Prozesse der Inhalt des Kopfteiles "Host" verwendet. Bei der Bildung des Schlüssels im Cache wird der Kopfteil "Host" verwendet.
Die Fahne MP zusammen mit PH arbeitet korrekt, seit der Version 1.0.20.
Wenn Frontend und Backend verschiedene Anschlüße verwenden, so korrigiert mod_accel 1.0.12 den Anschluß in den Kopfteilen "Location" und "Refresh nicht". Seit der Version 1.0.13, mod_accel arbeitet mit diesen Kopfteilen korrekt.

Seit der Version 1.0.14, mod_accel prüft die Direktiven AccelPass aus dem virtuellen Server, und nur dann der Direktive aus dem bevorzugten Server zuerst. Solche Ordnung lässt zu, im bevorzugten Server die Direktive mit der Fahne PH aufzugeben, und dann, sie in einigen virtuellen Servern zu umdefinieren.

Seit der Version 1.0.16, mod_accel lässt zu, in der Direktive AccelPass den speziellen Hostnamen _the_same_host _, zum Beispiel, zu verwenden:

AccelPass / http://_the_same_host_:8080/

In diesem Fall wird mod_accel als IP-Adresse Backend die selbe IP-Adresse, dass auch bei Frontend verwenden. Man muss bemerken, dass unter Anwendung von diesem Hostnamen die Fahne PH automatisch festgestellt wird. Wenn zusammen mit dem Namen _the_same_host_ die Fahnen MC oder MW aufgegeben sind, aber ist die Fahne MP nicht aufgegeben, so wird für die Beschränkung der Zahl der Verbinden oder der wartenden Prozesse die ip-Adresse Hostes verwendet. Bei der Bildung des Schlüssels im Cache wird die IP-Adresse Backend verwendet.

Die Fahne MP zusammen mit _the_same_host_ arbeitet korrekt, seit der Version 1.0.20.

Seit der Version 1.0.27, Backend, zugänglich durch _the_same_host _, kann named-based die virtuellen Hoste verwenden.

Die Direktive AccelPassCookie

syntax: AccelPassCookie on|off
default: AccelPassCookie off
context: server config, virtual host, location, files

Die Direktive bestimmt, ob man cookie den Klienten Backend übergeben kann, wenn seine Antwort auf die Abfrage verschlüsselt im Prinzip sein kann. Da sich die Antworten auf die Abfragen mit identisch URL je nach dem Inhalt cookie unterscheiden können, so ist solche Antworten Cache verboten. Deshalb, wenn die Antwort verschlüsselt im Prinzip sein kann, so reihen sich in die Abfrage in Backend cookie, übergeben vom Klienten nicht ein. Es ist die Konfiguration jedoch möglich, wenn Backend selbst bezeichnet, welche Antworten Cache, und notwendig ist welche es - nicht gibt. In diesem Fall kann man die Sendung cookie Backend erlauben.

Die Direktive übergibt die Kopfteile "Cookie", kommend vom Klienten, und die Kopfteile "Set-Cookie", übergeben von Backend, aber beeinflusst sie Cache auf keine Weise.

Die Direktive AccelPassServer

syntax: AccelPassServer on|off
default: AccelPassServer off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.16 und mehr

Die Direktive bestimmt, ob man den Kopfteil "Server", bestimmt Backend speichern muss, oder dieser Kopfteil soll Frontendом bestimmt sein.

Die Möglichkeit, den eigenen Kopfteil "Server" festzustellen ist in Apache 1.3.24, und wenn mit dieser Version Apache mod_accel früher verwendet wird, als 1.0.16 erschienen, so wird dem Klienten der Kopfteil "Server", bestimmt Backend übergeben werden. Standardmäßig ist diese Direktive und mod_accel-1.0.16 ausgeschaltet, wie auch die vorhergehenden Versionen, übergibt der Kopfteil Backend "Server nicht".

Bei der Nutzung mit Apache 1.3.26 ist eben älterer und mod_accel der Versionen 1.0.16-1.0.20 wird der Kopfteil "Server" überhaupt nicht ausgegeben, wenn die Direktive ausgeschaltet ist. Es ist in mod_accel-1.0.21 korrigiert.

Die Direktive AccelPassXAccel

syntax: AccelPassXAccel on|off
default: AccelPassXAccel off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.22 und mehr

Die Direktive bestimmt, ob man dem Klienten den Kopfteil "X-Accel-Expires", bestimmt Backend übergeben muss. Diese Direktive ist unter Anwendung von der Kaskade von zwei mod_accel, dann auf dem Server, der zu Backend näher ist nützlich, man muss die Sendung X-Accel-Expires für erstes Frontend erlauben.

Die Direktive AccelRetry5XX

syntax: AccelRetry5XX on|off
default: AccelRetry5XX on
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.18 und mehr

Die Direktive bestimmt, ob man versuchen muss, sich mit anderem Backend zu verbinden, wenn das Ergebnis der Antwort 5XX gleich ist und es wird die primitive Zuordnung der Belastung und Fehler Resistanz verwendet.

Die Direktive AccelRequestBuffSize

syntax: AccelRequestBuffSize
default: AccelRequestBuffSize 8
context: server config, virtual host, location, files

Die Direktive bestimmt den Umfang des Puffers in den Kilobytes für die Aufnahme des Körpers der Abfrage. Wenn der Umfang des Letzten den Umfang des Puffers übertritt, so wird die temporäre Datei verwendet.

Die Direktive AccelRevalidateUser

syntax: AccelRevalidateUser on|off
default: AccelRevalidateUser off
context: server config, virtual host, location, files

Die Direktive kann man verwenden falls alle untengenannten Bedingungen eingehalten werden:

Die Autorisation des Klienten wird Backend mittels des Kopfteiles "Authorization" oder cookie erfüllt;
Die Antwort Backend für verschiedene Benutzer identisch und folglich kann aus dem Cache zurückgegeben werden;
Die Autorisation ist eine billige Operation im Unterschied von der Erzeugung des Körpers der Antwort;
Backend versteht, die Kennzahl der Antwort 304 (HTTP_NOT_MODIFIED) und es zurückzugeben ist eine billige Operation im Vergleich zur Erzeugung der vollen Antwort.

Wenn die Direktive, so beim Vorhandensein im Cache der Antwort auf die Abfrage aktiv ist, wird die Abfrage zu Backend mit dem Kopfteil "If-Modified-Since" erfüllt.

Die Direktive AccelReverse

syntax: AccelReverse das Präfix url
default: nein
context: server config, virtual host
compatibility: mod_accel 1.0.10 und mehr

Die Direktive bestimmt, welche URL in den Kopfteilen "Location" und "Refresh" korrigiert werden sollen. Zum Beispiel, wenn die Direktive aufgegeben ist

AccelReverse / http://backend/

Und der Kopfteil "Location" enthält "http://backend/test/two.html", so wird er auf "http://frontend/test/two.html" geändert sein.

Die Direktive AccelReverse ist der Direktive ProxyPassReverse des Bausteines mod_proxy ähnlich, jedoch muss man sie zusammen mit der Direktive AccelPass nicht verwenden, da AccelPass schon die Funktionalität AccelReverse hat. Das Gebiet der Anwendung der Direktive AccelReverse — die Nutzung mod_accel zusammen mit dem Baustein mod_rewrite.

Seit der Version 1.0.26, AccelReverse kann für die Korrektion der Kopfteile verwendet werden unabhängig davon, wie Proxy — mit Hilfe AccelPass oder dem Baustein mod_rewrite wird .

Die Direktive AccelSendSize

syntax: AccelSendSize der Umfang
default: AccelSendSize 8
context: server config, virtual host, location, files

Die Direktive bestimmt den Umfang des Puffers in den Kilobytes für die Sendung der Antwort Backend dem Klienten.

Die Direktive AccelSetXHost

syntax: AccelSetXHost on|off
default: AccelSetXHost off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht den Kopfteil "X-Host" in die Abfrage, übergeben Backend zu ergänzen. In diesem Kopfteil wird der Inhalt des Kopfteiles "Host", übergeben Frontend vom Klienten übergeben.

Die Direktive AccelSetXRealIP

syntax: AccelSetXRealIP on|off
default: AccelSetXRealIP off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht den Kopfteil "X-Real-IP" in die Abfrage, übergeben Backend zu ergänzen. In diesem Kopfteil wird die IP-Adresse übergeben, von der die Abfrage zu Frontend gemacht war.

Die Direktive AccelSetXURI

syntax: AccelSetXURI on|off
default: AccelSetXURI off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.18 und mehr

Die Direktive bestimmt, oder nicht den Kopfteil "X-URI" in die Abfrage, übergeben Backend zu ergänzen. In diesem Kopfteil wird URI, übergeben Frontend vom Klienten übergeben.

Die Direktive arbeitet, nur seit der Version 1.0.28.

Die Direktive AccelSetXURL

syntax: AccelSetXURL on|off
default: AccelSetXURL off
context: server config, virtual host, location, files

Die Direktive bestimmt, oder nicht den Kopfteil "X-URL" in die Abfrage, übergeben Backend zu ergänzen. In diesem Kopfteil wird URL, übergeben Frontend vom Klienten übergeben.

Die Direktive AccelTimeout

syntax: AccelTimeout "die Uhrzeit" ["die Uhrzeit"]
default: AccelTimeout Timeout Timeout
context: server config, virtual host, location, files

Die Direktive gibt time outы bei der Arbeit mit Backend auf. Der erste Parameter bestimmt time out bei der Sendung der Abfrage Backend und die Lektüre seiner Antwort. Der zweite Parameter bestimmt time out auf das Verbinden mit Backend. Beider Parameters kann man in Form von der Zeile, zum Beispiel, "1 minute 30 seconds" oder in Form von einer Zahl aufgeben, die die Sekunden bedeutet. Wenn time out auf das Verbinden nicht angegeben ist, ist er dem Wert des ersten Parameters gleich. Man muss bemerken, dass bei der Systemanfrage connect () unverändert time out ist und in der Regel ist er 75 Sekunden gleich, deshalb, time out auf das Verbinden mehr als 75 Sekunden aufzugeben hat den Sinn nicht. Standardmäßig sind die Werte beider Parameter dem Wert der Direktive Timeout, die time out bei der Arbeit mit dem Klienten aufgeben gleich.

Groß time out bei der Arbeit mit Backend aufzugeben hat den Sinn, falls bis zum Ablauf time outа die Antwort von Backend und diese Antwort cached doch bekommen sein kann. Dann werden die nachfolgenden Abfragen aus dem Cache zurückgegeben werden, bis die Antwort veralten wird. In diesem Fall ist es empfehlenswert, von der Direktive AccelBusyLock des Wertes busy lock groß, als den Wert time outа festzustellen.

Die kleinen Werte beider time outs aufzugeben es ist für die Realisierung der primitiven Zuordnung der Belastung und Fehler Resistenz empfehlenswert.

Die Direktive AccelUnlinkNoCached

syntax: AccelUnlinkNoCached on|off
default: AccelUnlinkNoCached off
context: server config, virtual host, location, files

Die Direktive bestimmt, ob man aus dem Cache die Antworten löschen muss, selbst wenn sie verschlüsselt nicht sein können.

Die Direktive AccelWaitBeforeBodyRead

syntax: AccelWaitBeforeBodyRead die Uhrzeit in den Millisekunden
default: AccelWaitBeforeBodyRead 0
context: server config, virtual host, location, files

Die Direktive bestimmt die Wartezeit in den Millisekunden zwischen der ersten und zweiten Lektüre der Antwort Backend.

Die bekannten Fehler und die Besonderheiten

das Modul mod_accel arbeitet mit Backendми, unterstützend das Protokoll HTTP/1.0 und mehr.
das Modul mod_accel richtet zu Backend laut des Protokolles HTTP/1.0 Anfrage.
Wenn auf Frontend etwas Kopfteile "Set-Cookie" ergänzt werden, so wird in die Antwort, die vom Baustein mod_accel zurückgegeben wird, nur ein solcher Kopfteil ergänzt.
das Modul mod_accel unterstützt die Methode TRACE nicht.
das Modul, möglich, wird sich auf nicht-Unix die Bahnsteige versammeln, aber keiner Körperbewegungen nach Port wurde.

Der Manager des Caches

Bei der Montage mod_accel ebenso versammelt sich der Manager des Caches unter der Bedingung, dass mod_accel konfigurieren mit dem Parameter nicht war --without-cachemgr. Mit Hilfe des Managers des Caches kann man oder löschen abgesonderte URL im Cache erneuern. Dazu, dass der Manager des Caches auf Anfrage "/cachemgr" zugänglich wäre, man muss solche Direktiven aufgeben:

<Location/cachemgr> 
    SetHandler "accel-cachemgr" 
</Location>

Danach kann der Manager des Caches mit zwei Parametern — "/cachemgr?action=<action>&url=<url>" veranlassen sein , wobei url unbedingt Letzter sein soll. Der Parameter action kann zwei Werte übernehmen: refresh — für die Erneuerung des enthaltenen Caches und remove — für das Löschen der Datei aus dem Cache. Die Handlung remove arbeitete in Versionen mod_accel 1.0.4-1.0.24 nicht. Der Parameter url soll ohne Präfix "http://", des Hostnamens und des Anschlußes protzen. Bei der Antwort cachemgr ergänzt drei Kopfteile:

X-Accel-Cachemgr-Action Bezeichnet, welche Handlung vom Manager unternommen war. Kann die folgenden Werte übernehmen: create — war die Datei des Caches erstellt, refresh — war die Datei des Caches erneuert, remove — war die Datei des Caches gelöscht.
X-Accel-Cachemgr-URL Bezeichnet URL, der dem Manager aufgegeben war.
X-Accel-Cachemgr-Status Bezeichnet das Ergebnis des Ausführens der Operation. Kann die folgenden Werte übernehmen:
- success — ist die Operation erfolgreich erfüllt;
- invalid — der Fehler in den Parametern, die dem Manager des Caches übergeben sind;
- no_accelerated — Wird die Abfrage vom Baustein mod_accel nicht bearbeitet;
- not_found — Ist die Datei im Cache (bei der Operation remove) nicht gefunden oder Backend hat die Antwort 404 (HTTP_NOT_FOUND) zurückgegeben;
- no_cachable — Die Antwort Backend nicht gecached;
- cache_error — Der Fehler bei der Arbeit mit Cache;
- backend_error — Der Fehler bei der Arbeit mit Backend.

das Modul mod_randban

das Modul mod_randban ersetzt die Zufallszahl in den Antworten des Bausteines mod_accel.

Die Direktive RandomBanner

syntax: RandomBanner on|off|строка die Länge
default: nein
context: server config, virtual host, location, files

Die Direktive bezeichnet, die aufgegebene Zeile zu suchen und, das Folgende hinter ihr die Zahl von der Zufallszahl zu ersetzen. Die maximale Zahl der ersetzten Symbole wird im zweiten Parameter der Direktive angewiesen. Dabei werden sich die gehenden nacheinander identischen Zahlen gegen die identischen Zufallszahlen ändern. Zum Beispiel, der Direktive

RandomBanner random=rb 10 
RandomBanner rand = 10

Wird den Text ersetzen

<a href = "http://host/path0?place=1&random=rb00000"> 
<img src = "http://host/path1?place=1&random=rb00000"> 
</a> 

<a href = "http://host/path0?place=1&key=1234"> 
<img src = "http://host/path1?place=1&key=1234&rand=11111"> 
</a> 

<a href = "http://host/path0?place=1&random=rb00000"> 
<img src = "http://host/path1?place=1&random=rb00000"> 
</a>

Auf solchem:

<a href = "http://host/path0?place=1&random=rb42943"> 
<img src = "http://host/path1?place=1&random=rb42943"> 
</a> 

<a href = "http://host/path0?place=1&key=1234"> 
<img src = "http://host/path1?place=1&key=1234&rand=31520"> 
</a> 

<a href = "http://host/path0?place=1&random=rb06172"> 
<img src = "http://host/path1?place=1&random=rb06172"> 
</a>

das Modul mod_quoted

das Modul mod_quoted re-codiert die russischen Symbole in den Antworten des Bausteines mod_accel, vorgestellt in der Art quoted printable, in den Konstruktionen der Art ' <a href = "/show?page=2&word=%80%81%82"> '. Solche Konstruktionen werden bei der Ausgabe der Ergebnisse der Suche für die Verbannungen auf die bleibenden Seiten mit den Ergebnissen der Suche gewöhnlich verwendet. Die Symbole in den Verbannungen der Art ' <a href =...> '. Obwohl sich die verschlüsselten Symbole in den Verbannungen der Art ' <img src = im Prinzip treffen können...> ' oder ' <iframe src =...> ', in der Praxis solcher kommt es nicht vor. Die Umkodierung verwirklicht sich mit Hilfe des Bausteines mod_charset und paßt von seinen Direktiven an.

Die Direktive RecodeQuoted

syntax: RecodeQuoted on|off
default: off
context: server config, virtual host, location, files

Die Direktive erlaubt oder verbietet die Umkodierung quoted printable der Symbole.

das Modul mod_freeze

das Modul mod_freeze frostet viel zu aktiv Tags und die Parameter in den Antworten des Bausteines mod_accel:

Tag ' <script...> ', ' <object...> ', ' <iframe...> ', ' <style...> ', ' <layer...> ', ' <ilayer...> ', ' <applet...> ' und ' <embed...> ' und entsprechend ihnen schließend Tag;
Die Parameter innerhalb jedes Tag ' onBlur ', ' onChange ', ' onFocus', ' onSelect ', ' onSubmit ', ' onReset ', ' onMouseOver ', ' onMouseUp ', ' onMouseOut ', ' onMouseDown ', ' onMouseMove ', ' onClick ', ' onDblClick ', ' onKeyUp ', ' onKeyDown ', ' onKeyPress', ' onLoad ', ' onUnload ', ' onAbort ' und ' onError ';
Die Schemen der Adressierung in den Parametern ' javascript: ', ' livescript: ', ' behavior: ', ' vbscript: ', ' about: ' und ' mocha: '.

Das Einfrieren besteht in der Veränderung des letzten Symbols auf das Symbol ' X '. Zum Beispiel, ' <script...> ' wird auf ' <scripX ersetzt sein...> ', ' <onMouseOver...> ' — auf ' <onMouseOveX...> ', und ' <javascript:...> ' — auf ' <javascripX:...> '. Das Einfrieren fängt nach der Zeile an, die in der Direktive FreezeStart angegeben ist.

Die Direktive FreezeStart

syntax: FreezeStart die Zeile
default: nein
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.22 und mehr

Die Direktive gibt die Zeile auf, nach der Tags und die Parameter gefrostet werden. Standardmäßig fängt das Einfrieren mit dem Anfang der Antwort an.

Bis zu Version mod_accel 1.0.23 standardmäßig fing das Einfrieren nach Tag body an. Außerdem konnte man die Direktive nur global für den ganzen Server aufgeben.

Die Direktive FreezeTags

syntax: FreezeTags on|off
default: off
context: server config, virtual host, location, files
compatibility: mod_accel 1.0.22 und mehr

Die Direktive erlaubt oder verbietet die Veränderung der Tags.

Die Wechselwirkung mit dem Baustein mod_rewrite

Obwohl bei der Installation mod_accel das Modul mod_proxy fortsetzt, zu arbeiten, verhält sich es zur Fahne P der Direktive RewriteRule des Bausteines mod_rewrite nicht, wenn, natürlich, das Modul mod_accel konfigurieren mit dem Parameter nicht war --without-mod_rewrite.

Bei der Nutzung mod_accel kann man in der Direktive RewriteRule die Fahnen MC, MW und MP, wie in der Direktive AccelPass verwenden:

RewriteRule ^/one.html $ http://backend/$1 [P, MC=10, MP=Tsome]

Mit einer Ausnahme — in der Fahne MP darf man nicht den Wert L verwenden.

Die Unterstützung der Fahne MP in der Direktive RewriteRule ist in mod_accel, seit 1.0.6 erschienen. In den früheren Versionen die Ressource kann man nur vom Namen Backend beschränken.

Den ersten Parameter der Direktive RewriteRule kann man in SSI, zum Beispiel, verwenden:

<!--#include virtual = "/one.html? arg=one"->

Die volle Unterstützung der Direktive RewriteRule ist in mod_accel, seit der Version 1.0.5 gewährleistet.

Seit mod_accel die Versionen 1.0.10, mit Hilfe der Direktive AccelReverse kann man die Kopfteile "Location" und "Refresh" korrigieren:

AccelReverse / http://backend/

Seit mod_accel die Versionen 1.0.29, bei Proxy mit Hilfe des Bausteines mod_rewrite kann man den Kopfteil "Location" und "Refresh" mit Hilfe dieses Bausteines abschreiben. Zum Beispiel, die Abfrage "http://frontend/one/test" mit Hilfe der Direktive

RewriteRule ^ / ([^/] +) / (. *) $ http://$1.backend/$2 [P, L]

Wird auf "http://one.backend/test" gerichtet sein. Wenn sich "test" als den Katalog erweisen wird, so auf "http://one.backend/test/" zurückgeben. Es redirect kann man auf Frontend abschreiben, den Namen Backend bei der Prüfung der variabelen "ACCEL_REWRITE - Umgebung bezeichnet:

RewriteCond % {ENV:ACCEL_REWRITE} ^ ([^.] +) \.backend $ 
RewriteRule ^ (. *) $ http://frontend/%1/$1 [P, L] 

RewriteRule ^ / ([^/] +) / (. *) $ http://$1.backend/$2 [P, L]

Die Regeln, die die Kopfteile "Location" und "Refresh" abschreiben, sollen vor den Regeln gehen, die Proxy beschreiben.

Seit der Version 1.0.30, die obenangeführte Prozedur mit dem Baustein mod_rewrite wird mit Hilfe der Direktive AccelModRewriteLocation erlaubt.

Die Anpassung der Produktivität

Die Nutzung der Direktiven AccelIgnoreNoCache, AccelIgnoreAuth, AccelBusyLock, AccelMaxStale und die Beschränkung der Zahl der Verbinden lässt zu, die Belastung zu verringern, verschlüsselt die Antworten zurückgebend.

Die Vergrößerung des Umfanges des Puffers der Aufnahme der Daten von Backend von der Direktive AccelBkRcvBuffSize lässt zu, die Nutzung der temporären Datei als Puffer zu vermeiden. Für Antworten ist es nicht so kritisch, da diese temporäre Datei in die Datei des Caches nachher wird. Wenn der Umfang der Antwort den Umfang des Puffers im Gedächtnis übertritt, so wird in ErrorLog die Warnmeldung geschrieben: "accel: request... is buffered to tempfile".

Die Installation der Direktive AccelUnlinkNoCached in den Zustand off lässt zu, die chesch-Funktion md5 für die Abfragen nicht zu halten, die genau nicht werden.

Da die Systemanfragen die genug kostspieligen Operationen sind, so führt die Verkleinerung ihrer Zahl zur Vergrößerung der Produktivität des Systems. Wir betrachten die Weisen der Verkleinerung der Zahl der Systemanfragen bei der Arbeit mod_accel.

Wenn ethernet verbunden sind, so wird die Antwort von den Blöcken auf 1460 Bytes oder den Blöcken vom Umfang divisibel 1460 oft gelesen. In diesem Fall kann die Antwort vom Umfang 20K für 10-15 Paare Systemanfragen select () und read () gelesen sein. Wenn mit Hilfe der Direktive AccelWaitBeforeBodyRead, 200-300 Millisekunden zu erwarten, bevor den Körper der Antwort, jenen, vollkommen wahrscheinlich zu lesen, dass der Kern für diese Uhrzeit wenn die ganze Antwort, so wird selbst wenn seinen großen Teil, und die Antwort allen für ein oder mehrere Paare Systemanfragen select () und read gelesen sein (übernehmen wird). Natürlich, der Kern kann die ganze Antwort für Mal nicht übernehmen, wenn es der Umfang seines Puffers mehreren Umfang der Antwort gibt, deshalb, möglich, man muss den Umfang des TCP-Puffers der Aufnahme im Kern mit der Direktive AccelBkRcvSockBuffSize vergrössern. Außerdem dazu, dass die Antwort wiegen würde war gelesen aus dem TCP-Puffer des Kernes für einmal es ist notwendig, was der Umfang des Puffers, der von der Direktive AccelBkRcvBuffSize aufgegeben wird nicht weniger Umfang des Puffers des TCP-Puffers des Kernes war. Die Handlung der obenangeführten Direktiven analysieren es kann mit Hilfe der Notizen "accel_bnr", "accel_bfr", "accel_br", in die entsprechend die Zahl der Lektüren Backend, den Umfang des Kopfteiles der Antwort und des Teiles der Antwort, abgelesen für die erste Lektüre, und die Gesamtgröße der Antwort gespeichert wird.

Die Vergrößerung des Umfanges des Puffers der Abfahrt gegeben dem Klienten von der Direktive AccelSendSize lässt zu, die Zahl der Systemanfragen select () und write (zu verringern). Man muss bemerken, dass select () nur für den Fall verwendet wird, wenn parallel mit der Abfahrt gegeben dem Klienten die Lektüre der Antwort von Backend geschieht. Wenn die Antwort vollständig abgelesen ist, so wird nur sperrend write () verwendet.

Die Vergrößerung des Umfanges des Puffers der Abfahrt gegeben dem Klienten von der Direktive AccelCacheSendSize lässt zu, die Zahl der Systemanfragen read () für die Lektüre der Antwort aus dem Cache und write () für die Abfahrt gegeben dem Klienten zu verringern.

Der Parameter noauto in der Direktive AccelCacheRoot lässt zu, keine Systemanfragen mkdir () für die Bildung der Zwischenverzeichnisse bei jeder Bildung der neuen Datei des Caches zu machen.

Wie mod_proxy mit Backend zusammenwirkt

Obwohl das Modul mod_proxy wie der Puffer zwischen dem schweren Server (mod_perl) oft verwendet wird und kommt er vom langsamen Klienten, mit dieser Aufgabe schlecht zurecht. Es ist damit verbunden, was mod_proxy die Antwort von Backend von den Blöcken nach 8K liest und von solchen Blöcken gibt seinem Klienten zurück. Nach dem Erhalten der ganzen Antwort mod_proxy veranlasst die Funktion ap_bflush (), die die bleibenden Daten aus dem inneren Puffer Apache vom Umfang 4K in Socket den Klienten speichert. Und nur schließt danach mod_proxy Socket Backend. Wenn in der Qualität Backend Apache, so erfüllt er nach der Sendung aller Daten Frontend verwendet wird, macht Funktion lingering_close () — shutdown () auf die Aufnahme in Socket und, in select erwartet () schließen ' е 2 Sekunden, Socket.

So wird die ganze Pufferung nicht mod_proxy eigentlich erfüllt, und vom Kern und hängt nur von den Umfängen der TCP-Puffer der Aufnahme und der Abfahrt im Kern auf dem Wagen mit mod_proxy und vom Umfang des TCP-Puffers der Abfahrt auf Backend ab. Wir betrachten die Varianten der Situationen bei der Arbeit mit dem langsamen Klienten (die Geschwindigkeit daneben 3K/s), die auf FreeBSD die Versionen 3.0-4.3 entstehen können, wo der Umfang dieser Puffer 16K standardmäßig gleich ist.

Wenn der Umfang der übergebenen Daten den Umfang des TCP-Puffers der Abfahrt auf Frontend nicht übertritt, so wird Backend tatsächlich sofort nach der Sendung aller Daten Frontend befreit. Aus dem Puffer der Abfahrt Backend geraten alle Daten in den Puffer der Aufnahme Frontend sofort. mod_proxy lest sie nach 8K schnell aus und speichert in den Puffer der Abfahrt und danach schließt Socket zu Backend.
Wenn der Umfang der übergebenen Daten den summarischen Umfang der TCP-Puffer der Abfahrt und der Aufnahme Frontend, des TCP-Puffers der Abfahrt Backend und des inneren Puffers mod_proxy, gleich 8K, (für unseren Fall den summarischen Umfang 56K nicht übertritt), so wartet Backend noch zwei Sekunden nach der Sendung aller Daten Frontend. Es geschieht deswegen, dass der Puffer der Abfahrt Frontend vollständig erste 16K gefüllt ist, die Folgenden 8K sind mod_proxy abgelesen, noch befinden sich 16K im Puffer der Aufnahme Frontend und die Letzten 16K befinden sich im Puffer der Abfahrt Backend., Bis Frontend dem Klienten erste 16K übergeben wird (wird und es neben 5 Sekunden einnehmen), kann mod_proxy in den Puffer der Abfahrt die bleibenden Daten nicht speichern und entsprechend kann Socket zu Backend nicht schließen.
Wenn es der Umfang der übergebenen Daten als mehrere summarischen Umfang der TCP-Puffer der Abfahrt und der Aufnahme Frontend, des TCP-Puffers der Abfahrt Backend und des inneren Puffers mod_proxy gibt, so ist Backend im Laufe von der Uhrzeit, die für die Sendung dem langsamen Klienten der Daten notwendig ist, der den summarischen Umfang übertretenden Puffer, das Plus noch zwei Sekunden nach der Sendung aller Daten Frontend beschäftigt.

Man muss sagen, dass diese zusätzlichen 2 Sekunden in Apache, das heißt nirgends fixiert werden, sie darf man nicht in den Hohlwegen in der Ausführungszeit der Abfrage - %T und in der Abfrage server-status sehen, da die Uhrzeit nicht berücksichtigt wird, die auf lingering_close aufgewendet ist (), in %T auch wird der Prozess wie frei in scoreboard noch bis zum Aufruf lingering_close bezeichnet (). Die einzige Weise diese zwei Sekunden zu sehen sind die Mannschaft auszuführen netstat Auf Backend und anzuschauen, es ist Socketов, verbindend Backend und Frontend wieviel, befinden sich im Zustand FIN_WAIT2. Socket geht in diesen Zustand nach dem Aufruf Backend shutdown () und des Erhaltens der Bestätigung vom Kern Frontend über. Jedoch muss man bei der Analyse berücksichtigen, dass Socket in diesem Zustand und bleiben kann, nachdem Backend 2 Sekunden abgewartet hat und hat close () veranlassen, das heißt, ist zur Bearbeitung der neuen Abfrage schon fertig.

Die Wartezeit Backend bei der Aufnahme der großen Antworten verringern es kann mit Hilfe der Direktive ProxyReceiveBufferSize aufgebend den Umfang des TCP-Puffers der Aufnahme im Kern, und SendBufferSize aufgebend den Umfang des TCP-Puffers der Abfahrt im Kern. Außerdem kann man die Umfänge aller TCP-Puffer auf Frontend und Backend mit den Mitteln des Betriebssystemes vergrössern. Jedoch entfernt die Vergrößerung des Puffers der Abfahrt auf Frontend das Problem 2 Sekunden- Latentzeiten nur. 2 Sekunden- Latentzeiten vermeiden es kann, wenn Backend mit dem Parameter zu sammeln -DNO_LINGCLOSE.

In Apache 1.3.24 ist das Problem der Wechselwirkung mod_proxy teilweise entschieden und Backend — ist die Direktive ProxyIOBufferSize, zulassend erschienen, den Umfang des Puffers für das Erhalten der Antwort von Backend aufzugeben. Außerdem wenn von Backend die ganze Antwort bekommen ist, so wird das Verbinden mit ihm geschlossen, was zulässt 2 Sekunden- Latentzeiten zu vermeiden. Nichtsdestoweniger, das Problem ist nicht vollständig entschieden — wenn der Umfang der Antwort Backend mehr Summen des Umfanges des aufgegebenen Puffers und der nuklearen TCP-Puffer wird, so wird Backend auf die Uhrzeit, die für die Sendung des Teiles der Antwort notwendig ist, übertretend den summarischen Umfang der Puffer beschäftigt sein.

Außer dem synchronen Erhalten der Antwort der Antwort von Backend und der Rückerstattung seinem Klienten, mod_proxy ebenso übernimmt den Körper der Abfrage des Klienten synchron und übergibt es Backend.

Bei der Nutzung mod_accel gibt es kein solches Problem, da die Lektüre aus Socketа Backend und die Aufnahme in Socket des Klienten asynchron erfüllt werden, alle Operationen nicht blockierend und wird die Bereitschaft beider Socket mit der Hilfe select () ' a geprüft. mod_accel lest die Antwort von Backend in den Puffer aus, dessen Umfang mit der Direktive AccelBkRcvBuffSize protzt. Wenn der Umfang der Antwort den Umfang des Puffers übertritt, so wird der Inhalt des Puffers in die temporäre Datei gespeichert. Wenn die Antwort cached, so diese temporäre Datei später in die Datei des Caches. Außerdem gibt es die Direktive AccelBkRcvSockBuffSize, die ebenso, wie und ProxyReceiveBufferSize zulässt den Umfang des TCP-Puffers der Aufnahme im Kern mit jenem Unterschied aufzugeben, dass der Umfang in den Kilobytes, und nicht in den Bytes protzt. Jedoch ist sie in mod_accel für die Verkleinerung der Zahl der Systemanfragen select () und read (), notwendig für die Lektüre der Antwort Backend vorbestimmt.

Betreffs des Körpers der Abfrage, so nimmt es sich vom Klienten vollständig vor und nur danach wird Backend übergeben. Der Umfang des Puffers für die Aufnahme protzt mit der Direktive AccelRequestBuffSize. Wenn der Körper der Abfrage als Umfang des Puffers ist mehr, so wird es in die temporäre Datei gespeichert.

Das Modul mod_accel

Der Inhalt

Die Installation

Das dynamische Laden

Wie es arbeitet

Wenn die Antwort aus dem Cache bekommen sein kann

Busy lock

Die Beschränkung der Zahl der Abfragen

Die primitive Zuordnung der Belastung und Fehler Resistanz

Welche Antworten Caching

Die Notizen, mit deren Hilfe man den Baustein verwalten kann

Wie mit cookie zu arbeiten

Dass man in den Hohlweg speichern kann

Das Reinigen des Caches

Die Direktiven

Die Direktive AccelAddVia

Die Direktive AccelAddXForwardedFor

Die Direktive AccelBkRcvBuffSize

Die Direktive AccelBkRcvSockBuffSize

Die Direktive AccelBusyLock

Die Direktive AccelCacheCookie

Die Direktive AccelCacheRoot

Die Direktive AccelCacheSendSize

Die Direktive AccelCacheSetCookie

Die Direktive AccelClean

Die Direktive AccelCleanLastAccessed

Die Direktive AccelContentTail

Die Direktive AccelDefaultExpire

Die Direktive AccelIgnoreAuth

Die Direktive AccelIgnoreExpires

Die Direktive AccelIgnoreNoCache

Die Direktive AccelInvalidate

Die Direktive AccelLastModifiedFactor

Die Direktive AccelMaxStale

Die Direktive AccelModRewriteLocation

Die Direktive AccelNoCache

Die Direktive AccelNoPass

Die Direktive AccelPass

Die Direktive AccelPassCookie

Die Direktive AccelPassServer

Die Direktive AccelPassXAccel

Die Direktive AccelRetry5XX

Die Direktive AccelRequestBuffSize

Die Direktive AccelRevalidateUser

Die Direktive AccelReverse

Die Direktive AccelSendSize

Die Direktive AccelSetXHost

Die Direktive AccelSetXRealIP

Die Direktive AccelSetXURI

Die Direktive AccelSetXURL

Die Direktive AccelTimeout

Die Direktive AccelUnlinkNoCached

Die Direktive AccelWaitBeforeBodyRead

Die bekannten Fehler und die Besonderheiten

Der Manager des Caches

das Modul mod_randban

Die Direktive RandomBanner

das Modul mod_quoted

Die Direktive RecodeQuoted

das Modul mod_freeze

Die Direktive FreezeStart

Die Direktive FreezeTags

Die Wechselwirkung mit dem Baustein mod_rewrite

Die Anpassung der Produktivität

Wie mod_proxy mit Backend zusammenwirkt

TIPP DES TAGES

PC-Forum - Alle Forenthemen

Testberichte & Reviews über PC-Hardware, Computer und Spiele auf PCMasters.de