Apache konfigurieren

[Michael Schröpl]

Hi Andreas,

"schlank" und "mod_rewrite" unter einen Hut zu bekommen ist ein echtes Kunststück.
och sagte "möglichst" schlank. mod_rewrite ist das wichtigste Apache-Modul welches ich brauche.

Ich habe mod_rewrite noch nie gebraucht ...

Mal was allgemeines, sollte ich möglichs alle Module die ich brauche einkompilieren, oder nur die die ich andauernd brauche? Also rewrite und php?

Was verstehst Du unter "andauernd"? Ist das ein Produktions-Apache oder nur einer für Dich zum "spielen"?

"mod_rewrite" ist bei Apache 1.3 das größte Einzelmodul nach Code-Datei-Umfang (vor mod_include, glaube ich mich zu erinnern); brauchst Du das _wirklich_?
ja, für meine modulare Struktur.

Diese Erklärung überzeugt mich nicht.
Was brauchst Du denn, was Du nicht mit sehr viel billigeren Methoden (Aliasse etc.) umsetzen kannst?

| Und mod_gzip für Apache 2 ... hm.
mod_deflate ist glaube ich das pendant, daher auch --enable-deflate. Aber davon sehe ich auchs nichts unter httpd -l. Vermutlich braucht er hierfür die zlib,

Ja. Definitiv.

--enable-file-cache
--enable-cache
--enable-disk-cache
--enable-mem-cache
Ich wollte, ich könnte zu den ganzen Apache-2-cache-Modulen schon etwas sagen ... das ist jedenfalls (alles?) Performance-Tuning, nicht Funktionalität.
Ja, wenn ich ohne weitgeres Zutun nur durch diese paar Angaben bessere Performance erhalte

"Ohne weiteres Zutun" - nein. Fast alle Module stellen Dir lediglich Direktiven zur Verfügung - es ist dann Dein Job, diese zielgerichtet einzusetzen und damit Deine Aufgabenstellung zu modellieren.

mod_file_cache
New module in Apache 2.0. This module includes the functionality of mod_mmap_static in Apache 1.3, plus adds further caching abilities.

Eben. _Du_ kannst in diesen Cache Dinge laden - tust Du das?

--enable-deflate
Das jetzt also doch? Oben las es sich noch anders ... für Apache 2 ist das aber wahrscheinlich kein großer Unterschied.
mod_deflate
New module in Apache 2.0. This module allows supporting browsers to request that content be compressed before delivery, saving network bandwidth.

Yep - aber Du hattest oben "mod_gzip" genannt, nicht "mod_deflate".

--enable-expires
--enable-headers
Beides sinnvoll - aber nur, wenn Du es aktiv und richtig nutzt.
Hm ich denek ich brache es nicht, da nur wie gesagt ein PHP Projekt drauf läuft, aber vielleicht für Bilder etc. wiederum andere Dateien dürfen bloß nicht gecached werden.

Bilder, JavaScript, CSS, HTML ... sogar PHP-Ausgaben kann der Browser cachen. Es ist Dein Job, Dir ein Konzept der Lebensdauer für jede einzelne Seite zu überlegen, wenn Du dem Cache erklären willst, wie er am effizientesten mit Deinen Seiten umgehen kann.

--enable-http
Hoppla - das sagt mir gerade mal gar nichts ...
mir auch nicht, am besten weg damit.

So hatte ich das nicht gemeint. Ich bin mir bloß keines Moduls "mod_http" bewußt ...

--enable-rewrite
Nun gut ...
ICH BRAUCHE ES ;-)

Siehe oben.

--enable-so
Wozu brauchst Du mod_so, wenn Du doch beim Übersetzen einen maßgeschneiderten Apache zusammenbaust?
Ich überlege ob ich selten verwendete Module über DSO lade, so mod_perl z.B. das brauche ich nur zum parsen und schreiben von Excel-Dateien. Udn ich weiß nicht ob sich PHP _überhaupt_ in den httpd einkompilieren läßt.

Probiere es aus.

#--with-z=DIR
Ist da für die zlib? Wenn Du mod_deflate verwenden willst - das nutzt die zlib, die haben nichts Eigenes geschrieben (anders als mod_gzip).
Aber wie ich das verstanden habe macht mod_deflate "exakt" dasselbe wie mod_gzip, oder?

Wenn Du nur das Ergebnis betrachtest - ja (beinahe - modulo "Vary:"-Header).

Aber _wie_ das Ergebnis zustande kommt, d. h. wie fein Du beeinflussen kannst, wann was warum komprimiert ausgeliefert wird oder nicht, wie performant die Komprimierung erfolgt, _wann_ überhaupt komprimiert wird (mod_gzip 1.3.26.1a hat seinen eigenen Cache) usw., da kann mod_deflate nicht mithalten. Das ist eben ein reiner, "dummer" Komprimierungsfilter.

mod_gzip gibt es doch nicht für den 2er Apachen, oder?

Doch, das gibt es: http://www.pcp-computer.de/gkn/apache/httpd-2.0/win32/modules/
mod_gzip ist ja ursprünglich überhaupt erst für Apache 2.0 geschrieben und nach 1.3 zurück portiert worden, weil Apache 2 jahrelang nicht in die Gänge kam und ständig alle internen APIs inkompatibel geändert wurden ...

Geh doch mal mit einem "find / -name libz.a -ls" über die ganze Platte danach suchen ...
libz.a also, OK das reicht. .a ist immer für einzukompilierende Module, .so für DSO, oder?

Es kann sein, daß beides plattformabhängig ist. Bei mir auf Solaris heißen die während der Apache-Übersetzung lokal entstehenden Bibliotheken jedenfalls "lib*.a" und der Inhalt von /usr/local/lib ebenfalls; die Shared Objects können auf Windows beispielsweise beliebig heißen (mod_gzip funktioniert sowohl als *.so wie auch als *.dll mit demselben Inhalt - sofern die LoadModule-Direktive entsprechend aussieht).

Ist der Nachteil eine "alles drin was ich brache"-Aachen nur dieser das er für Erweiterungen neu kompiliert werden muß? Sonst ist das doch grundsätzlich schneller, oder?

Die *.so-Schnittstelle soll laut Dokumentation in der Tat ein paar Prozente langsamer sein. Auch das Starten des Apache wird durch das Nachladen der shared objects natürlich langsamer, aber das dürfte ziemlich unwichtig sein.

Und was ist mit MPM, sollte ich das ändern?
Das ist etwas, was Du gründlich lesen solltest, bevor Du es änderst ... das ist wohl eine Wissenschaft für sich.
Ja, halt grundsätzlich als worker-threads oder mit prefork, ich werde letzteres einfach nicht verändern, aber für später -  was ist wohl schneller?

Da mußt Du Dich an einen Apache2-Experten wenden - nicht an mich.

Wenn Du wirklich nur fünf Module brauchst, dann brauchst Du auch nur diese einzubinden.
(Du kannst übrigens mit "httpd -l" nachsehen, was tatsächlich alles eingebunden ist.)
ich binde aber nicht nur die Module ein. Es gibt ja auch genügend Parameter zum "Konfigurieren", das ist meine Sorge das mir da was fehlt.

Das merkst Du dann schon, wenn das Linken nicht funktioniert ... ;-)

Ich werde auch noch Apache 1 neu kompilieren, da gelten im Prinzip dieselben Regeln, oder?

Ja. Ich habe mir insbesondere die httpd.conf in ein System von etwa 20 Include-Dateien zerschlagen - soweit wie möglich alles nach Modulen sortiert, in bestimmten Teilen nach "features" (wo ich Direktiven verschiedener Module brauche, um thematisch zusammengehörige Dinge zu realisieren).
Deshalb weiß ich ja überhaupt, welche Module ich brauche und welche nicht - das ist einmalig ziemlich viel Arbeit, aber man lernt den Apache dabei richtig gut kennen.

Meine Virtual-Host-Abschnitte bestehen inzwischen fast nur noch aus Include-Anweisungen dieser "Bausteine".

Wenn das mod_gzip Modul ja nicht im Source enthalten ist, und ich es von sourcefourge runterlade, kann ich das trotzdem mit einkompilieren?

Ja, kannst Du. Falls Du auf einer Plattform arbeitest, für die es schon ein shared object gibt (BSD, Linux, Solaris), könntest Du auch dieses verwenden.

Viele Grüße
      Michael