nicht angemeldet
Halihallo Andreas
Sorry, wollte eigentlich auf ein OT schwenken ;-)
OK, jetzt wird mir einiges klar; ich habe verzweifelt versucht, dein Posting in einen
Zusammenhang mit Kays Frage zu bringen ;-)
Ich glaube, du hast mich falsch verstanden?
nein, aber ein "Logging-Server" sollte ja möglichst schlank sein. Ich finde das Thema nämlich interessant.
Oh, ich auch! ;)
Ich meine, letzterer HTTP-"Code" ist ja wirklich nicht schwer und sollte möglichst kurz und kann immer gleich sein.
[...] das lässt sich kaum in einem Tag selbstprogrammieren...KLar ;-) Aber ich will mich nur soweit an Standards halten wie es nöttig ist. Wenn ich Daten von Clients einer Homepage loggen will schreibe ich einen kleines C++ Programm, welches HTTP nicht interptrtieren muss, sondern nur "zuerpflücken" und loggen, udn damit es zu keinem Fehler kommt einen 200er Header zurücksenden. Ich dachte mir halt das einfachste wäre so ein Bild auf jeder Seite der Homepage einzubinden. Mehr muß man ja nicht können, und eben das interessiert mich ;-)
Da hätt ich noch ein zwei Tipps für dich:
Du schreibst ein C++ Programm, welches sich an Port 80 "anheftet" (es sei denn, du
möchtest parallel noch ein Webserver betreiben). Kommt ein Request, wird er so schnell
wie möglich ausgewertet, gibt einen möglichst kleine HTTP-Response (Netzwerktraffic
klein halten) und sendet das transparente 1x1 Pixel-GIF _gleich mit_, damit verhinderst
du einen zweiten Request auf den Webserver (doppelte Performance/Request). Das kleine
GIF braucht ca. 90 Byte, der HTTP-Header etwa 20 Byte, so kommst du auf ca. 110 Byte
pro Request.
Aber: Was, wenn 200 Requests/s eintreffen? - Lineares abarbeiten der Request Queue ist
hier einfach verdammt langsam. Besser geht's mit dem vorgeschlagenen preforking, optinal,
um's etwas einfacher zu machen, für jeden Request ein neuer Prozess (fork).
Ich arbeite gerade auch auf diesem Thema, hatte mir noch folgendes ausgedacht:
Warum _alles_ in den "Request-Dispatchern" verarbeiten? - Es wäre doch möglich, nur die
sofortigen Arbeiten (also die, die den Besucher unmittelbar betreffen, eg. Cookies)
zu erledigen und alles andere auf Flatfile basis zu speichern und von stündlichen
cron-Jobs erledigen zu lassen. Dies hätte mehrere Vorteile: komplexe Auswertungen kann
man über perl/php schreiben (in C++ portieren dürfte am Anfang etwas langwierig sein)
und man hat einmal/Stunde ein Prozess laufen, der eben etwas länger dauert, aber die
sehr oft aufgerufenen C-Tags sind saumässig schnell. Somit könnte man schätzungsweise
gegen die 500 Requests/s locker verarbeiten, trotz grossem mathematischen Aufwand die
Daten zu verarbeiten. Natürlich, unter dem Strich "verschwendet" man mehr Performance,
aber die zusätzlich verschwendete Performance der cron-Anwendungen kann man auf
ausserhalb der Stosszeiten auslagern und ist somit effizienter. So kann man selbst bei
Stosszeiten zuverlässig alle Requests in akzeptabler Zeit abarbeiten.
Danke das war es was mich interessierte ;-) Nur wenn ich das ganze mit PERL mache einst Du dann mod_perl + Apache?
mod_perl unter Apache bringt ca. die 10 fache Performance, als "normales Perl" unter
dem Apachen. Kommt natürlich stark auf den Kontext an, wobei dein Anwendungsfeld eben
_genau_ davon profitieren würde.
Aber dann habe ich ne ganze Menge Overhead für diese einfache Anwendung.
Findest du? - mod_perl lässt sich IMHO konfigurieren, wieviele parallele Instanzen
verwaltet werden sollen. Woraus hier ein grosser Overhead entsteht ist mir nicht klar.
Oder kann man auch einen PERL Prozess(bzw. mehrere) im Speicher halten, also das 1. nicht immer der Interpreter angeworfen werden muss(das ware das schlimmste)
Aber natürlich ;)
Mit Perl lassen sich ganz einfach und sehr schöne Daemonen programmieren und darum geht
es hier.
udn 2. das es schon im RAM ist und so nicht noch von der Platte geholt werden muss.
Was ist im RAM? - Die Perlinstanz?
Daher dachte ich an PHP da ich nicht sicher bin ob PERL das kann! Und das ganze über den Apachen laufen zu lassen wollte ich ja gerade vermeiden!
Du brauchst ein Script, dass im Hintergrund immer läuft... Das kann man sowohl in Perl,
als auch in PHP oder C. Wo siehst du hier einen Vorteil von PHP?
Viele Grüsse
Philipp