OT: performanter Server für HTTP-Logging

[Michael Schröpl]

Hi Andreas,

Und "statische Seiten" ist auch ein völlig untaugliches Kriterium. Nicht nur die dynamische Berechnung eines Seiteninhaltes kostet schließlich Zeit, sondern eine Vielzahl anderer Features, die vorher im Webserver gelaufen sein können:

• URL-Manipulation (mod_rewrite)
• Übersetzung von URLs in Pfadnamen (mod_alias, mod_dir, ...)
• Berechtigungsprüfung (mod_auth_*)
• Suche nach dezentralen Konfigurationsanweisungen für "Scopes" (.htaccess)
• Content Negotiation
  All diese Mechanismen sind _vor_ dem Zugriff auf eine _statische_ Datei bereits abgeschlossen - und wenn sie durchlaufen werden mußten, kostet sie natürlich Zeit.
  Statische Seiten ist für mich _nichts_ von alledem, einfach HTML ausliefern wie es angefragt wird, merh nicht.

Statische Seiten sind _alles_ von alledem - je nach Deiner Apache-Konfiguration.

Selbst wenn Du nur über ein DOCUMENT_ROOT adressierst, muß für jeden URL eine Umrechnung auf einen Pfadnamen erfolgen ... wenn Du zusätzlich Alias-Definitionen für Pfad-Mapping verwendest, wird es noch komplizierter, und wenn Du einander überlagernde Scopes auf verschiedene Festplattenbereiche legst, dann muß der Apache erst mal "ausrechnen", welche der vielen Übersetzungsvorschriften für die angeforderte statische Datei denn überhaupt zutrifft.

(Mir geht es hierbei nicht um Dein Szenario, sondern lediglich um die Untauglichkeit des beschriebenen Vergleichs-Kriteriums "statische Seite", die lediglich etwas über die _Erzeugung_ des Content aussagt, nichts aber über die Entscheidung, welche der vielen möglichen Erzeugungsmethoden überhaupt anzuwenden ist - und die kann eben auch beliebig unterschiedlich kompliziert sein, im Falle von mod_rewrite wird ja praktisch eine Interpreter-Programmiersprache dazwischen geschaltet.)

Deshalb verwende ich mod_so ja auch nicht, und mod_rewrite vermeide ich ebenfalls.
Für so einen Fall würde ich das auch nicht tun, wobei ich zur Zeit doch mod_so verwende, denn es ändert sich einfach noch zu viel an meinen Anforderungen, und irgednwann fängt ./configure...; make;  make install an zu nerven, vor allem das make beim Apache mit einigen einkompilierten Modulen schonmal die ein oder andere Minute dauert!

Das stört mich aber nicht - das läuft friedlich im Hintergrund (selbst auf einer Produktionsmaschine).
Und zudem habe ich ein Shell-Skript mit der Kommandofolge (natürlich tippe ich das irre lange "configure"-Statement nicht manuell ein), welches den Übersetzungsvorgang gespeichert hat - das kann ich auf eine beliebige Maschine kopieren und dort einen Apache so übersetzen, wie ich das für richtig halte.

Ich brache keinen Webserver der den Request erstmal parst, analysiert,
Doch, den brauchst Du. Du mußt schließlich HTTP unterstützen.
Wieso? Ich muß nur an einem Socket lauschen und schreibe das was da ankommt direkt ungesehen in eine Datei, als Antwort kommmt ein festgelegter Response, wozu muss ich da HTTP können?

Weil Du dem Request ggf. ansehen mußt, welche Responses Du senden _darfst_ und welche nicht.
Welche HTTP-Version unterstützt Du denn überhaupt? (1.1? 1.0? 0.9?)

Über mod_mmap_static kannst Du Deine Reponse im Hauptspeicher halten lassen und damit den Dateizugriff komplett vermeiden.
Sowas kann der Apache??? Interessant...
Du kennst mod_asis, das Dateien inklusive fertiger HTTP-Header unmanipuliert ausliefert?
und das auch...

Fast alles, was man sich vorstellen kann, "kann der Apache" - die Modul-API ist dokumentiert, und Du kannst Dir selbst jederzeit ein Modul schreiben.

mod_gzip ist ja auch nichts anders als der Versuch eines Programmierers, etwas zu implementieren, was "der Apache" alleine nicht kann, was man ihm aber über diese API nachrüsten kann.

Viele Grüße
      Michael