Andreas Korthaus: Apache konfigurieren

Beitrag lesen

Hallo!

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"?

Ich spiele hier bei mir rum, aber ich will genau dei Konfiguration in einigen Wochen auf einem Produktions-Server einsetzen. "andauernd" ist so eine Sache. Es haben nur bestimmte Leute Zugriff, aber das können schonmal ein paar sein, und wenn dann meist alle zur gleichen Zeit, also muß ich diese peaks aushalten, udn da habe ich mal grob überschlagen, sind es mit massig reservern höchtens 100 Requests pro Sekunde, aber die gehen dafür fast alle an wirklich komplexe PHP-Scripte, wo viel eingebunden wird(halt eigene modulare Struktur(konfdaten, userdaten, PEAR, PEAR::Auth, PEar::DB, Smarty(template-Engine)...)), das in jedem Script. Die Modularität war hier erheblich wichtiger als die Performance, aber trotzdem sollte das Teil nicht bei 50 gleichzeitigen anwesenden Anwendern zusammenbrechen ;-)
Der Server an sich ist einigermaßen Leistungsfähig, weiß jetzt nicht genau, aber eine X86 Architektur mit 500MB RAM und ich vermute mit einem halbwegs neuen PIII. Das weiß ich zur Zeit aber alles noch nicht genau. Dafür steht der komplette Server nur hierfür zur Verfügung.   Als OS kommt die Server-Version von RedHat Linux 7.3 oder 8.0. Ich habe jetz euin bisschen in  einer PHP-Liste rumgemailt, und die raten ganz entschieden von Apache 2 ab. Mit prefork versetzt man den Apachen in einen "apache-1-modus" so zu sagen, man hat also keinen Vorteil von Apache2, nur alle Nachteile. Außerdem kann ich PHP da definitiv nicht mit einkompilieren, udn genausowenig meinen favorisierten PHP-Cache verwenden. Spricht also nichts wirklich dafür ;-)

"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?

Hatte das ja oben kurz angeschnitten. _Alle_(außer images, index.php) Requests werden auf ein Script "index.php" umgeleitet, mit dem ursprünglichen Request als GET-Parameter. Dann entscheidet dieses Script was pasieren soll, stellt die Configre-,Request-...Variablen über eine Schnittstelle zur Verfügung, führt die Authentifikation durch, läd eine Error-Klasse, PEAR, ggfs. Smarty, läd entsprechend dem Request Module und diese dann ein Template und gibt dieses aus...

Das ganze war notwendig, da die Software Verschieden Benutzerebenen und unabhängige -Bereiche braucht, dazu merhsprachigkeit, und einfach hinzufügbare und entfernbare Plugins, die sich unterschiedlich auf die Benutzer auswirken(erweiterung der Menüstruktur(Userabhängig), zusätzliche Seiten und Scripte, Rechte...). das habe ich hier im Forum in einigen sehr großen und für mich sehr lehrreichen Threads vor allem mit Christian Seilers, Christian Kruses und Sven Rautenbergs(hoffe habe niemanden vergessen, wenn doch sorry :-( ) Hilfe entwickelt. Ob das so optimal ist kann ich noch nicht sagen, ich habe da halt überhaupt keine Erfahrung. Bitte sag mir jetzt nicht das dieser Aufbau totaler Quatsch ist :-)

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.

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.

Bei PHP-Ausgabe nicht ganz so einfach, siehe mein Struktur, vielleicht sollte ich solcher Headere hier lieber in PHP generieren?!

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

-enable-http           HTTP protocol handling

sagt mir nicht allzuviel, und finde es nicht in der Doku, ist auch egal, ich brauche es bestimmt nicht! Ich bin anfangs nur so nach namen u. Beschreibung gegangen, "könnte man vielleicht gebrauchen...".

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.

Wie schätzt Du das ein, sollte man (bei Apache 1) Module, auch wennm an sie seltener braucht mit einkompilieren? Wi eist das theoretisch? Vermutlich verlangsamt jedes einzelne Modul den Apache ein Stück, die Frage ist ob das beio DSO oder static genau gleich ist, oder ob DSO Module weniger ins Gewicht fallen, da sie ja nicht immer "mitgeschleppt" verden müssen.

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 ...

Würdest Du mod_gzip immer mod_deflate vorziehen? Sowohl Apache 1 als auch 2? Ich habe für das Projekt keine einzige HTML-Datei, die ein Cache speichern könnte. Meine Seiten ändern sich fast alle andauernd, manche sogar bei jedem Request.

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

Daher poste ich ja hier und schreibe Dir keine Mail ;-)

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.

Aber dann muss ich es ja wieder über DSO laden, ich will es doch statisch einkompilieren!

Danke vielmals für die Hilfe!

Grüße
Andreas

PS: Gegen PHP war der Apache richtig unproblematisch ;-)