Heim  >  Artikel  >  php教程  >  Apache-Leistungsoptimierung (3)

Apache-Leistungsoptimierung (3)

黄舟
黄舟Original
2016-12-21 11:25:001038Durchsuche

Im Folgenden werden einige wichtige Module besprochen, die nicht standardmäßig installiert sind. . (Außer Prefork)

Häufig verwendete Module:

Die am häufigsten verwendeten sind möglicherweise das Front-End von PHP- und JAVA-Anwendungsservern, die wir in unserer aktuellen Anwendung nicht benötigen. Darüber hinaus kann die Verwendung von mod_gzip im Hinblick auf die Leistung den Datenverkehr um etwa 40 % reduzieren und die Belastung des Computers für die Übertragung verringern. Die von uns verwendeten Dateien sind relativ klein, sodass wir sehen können, ob der Zeitaufwand des Komprimierungsalgorithmus und die Reduzierung der Übertragungslast kosteneffektiv sind. Mod_expires kann wiederholte Anfragen um etwa 10 % reduzieren, sodass wiederholte Benutzer die Ergebnisse bestimmter Seitenanfragen lokal zwischenspeichern können, ohne überhaupt Anfragen an den Server zu stellen. Da wir jedoch ein Speicherdateisystem verwenden, kann die Cache-Optimierung vollständig ignoriert werden.

WEB-Beschleunigung basierend auf Reverse-Proxy:

Sowohl Squid als auch mod_proxy können eine Reverse-Proxy-Beschleunigung erreichen. Die Cache-basierte Proxy-Beschleunigung wird um Größenordnungen schneller sein als der ursprüngliche WEB-Dienst. Das gleiche Speicherdateisystem ist nicht erforderlich.

Schlüsselindikator MPM, der sich auf die Leistung auswirkt:

MPM (Multi-Processing Modules, Mehrkanal-Verarbeitungsmodul). MPM sieht anderen Apache-Modulen sehr ähnlich. Im Gegensatz zu anderen Modultypen muss in Apache ein und nur ein MPM ausgeführt werden. . Die Methode zur Angabe von MPM

$ ./configure --help|grep mpm

wird wie folgt angezeigt:

--with-mpm=MPM

Wählen Sie das Prozessmodell aus, das Apache verwenden soll.

MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool🎜>

Beos und mpmt_os2 sind die Standardmodelle unter BeOS und OS /2 bzw. MPM, perchild ist hauptsächlich darauf ausgelegt, verschiedene untergeordnete Prozesse als unterschiedliche Benutzer und Gruppen auszuführen. Dies ist besonders nützlich, wenn mehrere virtuelle Hosts ausgeführt werden, die CGI erfordern, und leistet einen besseren Job als der SuExec-Mechanismus in Version 1.3. Sowohl Leader als auch Threadpool sind Worker-basierte Varianten und befinden sich noch im experimentellen Stadium. In einigen Fällen funktionieren sie nicht wie erwartet, daher empfehlen Apache-Beamte ihre Verwendung nicht. Daher beschäftigen wir uns hauptsächlich mit Prefork und Worker, den beiden MPMs auf Produktebene, die den größten Zusammenhang mit der Leistung haben.

Wenn Sie nicht explizit ein bestimmtes MPM mit „--with-mpm“ angeben, ist Prefork das Standard-MPM auf der Unix-Plattform.

Prefork selbst verwendet keine Threads, um die Kompatibilität mit Version 1.3 aufrechtzuerhalten. Prefork verwendet separate Unterprozesse, um verschiedene Anforderungen zu verarbeiten, und die Prozesse sind unabhängig voneinander, wodurch es zu einem wird eines der stabilsten MPMs.

Das Arbeitsprinzip von Prefork besteht darin, dass der Steuerungsprozess, nachdem er zunächst den Unterprozess „StartServers“ eingerichtet hat, einen Prozess erstellt, der den Anforderungen der MinSpareServers-Einstellung entspricht, eine Sekunde wartet und dann zwei weitere erstellt , und wartet eine weitere Sekunde. Fahren Sie mit der Erstellung von vier weiteren fort... Dadurch erhöht sich die Anzahl der erstellten Prozesse exponentiell auf bis zu 32 pro Sekunde, bis der von MinSpareServers festgelegte Wert erreicht ist. Hier kommt Prefork ins Spiel. Dieser Modus macht das Erstellen neuer Prozesse bei eingehenden Anforderungen überflüssig, wodurch der Systemaufwand reduziert und die Leistung gesteigert wird.

Das Obige ist der Inhalt der Apache-Leistungsoptimierung (3). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!


Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn