nicht angemeldet
Hi Philipp!
Oh, ich auch! ;)
Denke ich mir ;-)
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).
was meinst Du damit? Meine Idee war ja gerade die einen eigenen Mini-"Webserver" zu schreiben(bin durch Kay auf die Idee gekommen), also einen C++ Dämon der wie beschreiben auf Port 81 lauscht, HTTP Request direkt in eine File schriebt, nicht analysiert, und dem Client einen 200 Status-Code und ein gif zurücksendet. Dieser Dämon würde ja _superschlank_ und schnell sein, theoretisch. Ich habe keien AHnung wie man das macht da sman so einen Dämon-Prozess forkt(das ist sicher nicht schwer), aber das problem was ich erstmal sehen würde - wie verteile ich die Requests aif die verschiedenen Prozesse? Also es läuft meiN Dämon udn 50 Kopien dieses Prozesses. Lauschen jetzt alle an Port 81, wer entscheidet werd jetzt den Request entgegennimmt und bearbeitet? Oder muß da noch was "vor"?
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.
Das hatte ich mir so gedacht, so einfach wie möglich.
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).
Ist preforking Unix-spezifisch oder Apache-spezifisch? Ich kenen das nur vom Apachen, und da läuft das halt von alleine. Wenn ich das selbst implementieren wollte, ginge das auch in PERL?
Naja, mit Prozess-Lomunikation... muss ich mich wohl erstmal auseinandersetzen, das gibt es in PHP nicht wirklich, daher kenne ich es nicht wirklich ;-)
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.
Ja. Ich kann nicht genau beurteilen was genau wie lastenintensiv ist, nur so ganz grob. Daher denke ich man muß testen wie man das ganze aufteilt (laufzeit/cron). Einfach testen...
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.
So viel? Nicht schlecht. Ich denke das wäre für den Anfang das beste, um erstmal ein wenig zu lernen. Wenn es dann hart auf hart kommt kann man dann überlegen ob man den Apachen komplett aufgibt und erstmal einen speziellen Perl-HTTP-Dämon bastelt, und später das dann mit C++, wobei C++ sicher auch ineffizienter geht, dahe rsolt eman das wohl erst machen wen man da genügend Erfahrung hat. Und immer Lastests, habe irgendwo letzten Software gesehen dei Requests simuliert und den Server so unter last setzt.
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.
Hm, vielleicht irre ich mich auch. 99,99% der einkompilierten und geladenen Apache und mod_perl Funktionalitäten brauche ich nicht. Wäre es nicht günstiger einen Dämon zu schreiben der nur genau das kann und läd was ich brauche?
Aber ich weiß auch das ich nicht so effizient programmieren kann wie die Apache oder mod_perl Leute, daher ist es fraglich ob die Apache + mod_perl Variante nicht vielleicht doch die bessere Variante ist. ODer vielleicht sollt man einen anderen Server einsetzen: Zeus, thttpd, tux, khttpd sollen für statisches HTML schneler sin, nur vermutlich gibt es dafpr nict sowas effizientes wie mod_perl. Außerdem passt sich das Betriebssystem der Anforderung an, und hält genau die richtigen Dinge im Speicher. Schwirige Frage. Ich kenne mich da leider noch nicht genug aus.
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.
Hm? Sind mod_perl und perl-dämonen nicht 2 verschiedene paar Schuhe? Mod-Perl ist doch "nur" eine Webgserver - Schnittstelle, so ähnlich wie CGI, nur das es ebe nicht über CGI geht sondern über die Apache SAPI, und das ist eben erheblich effizienter. Hierüber können über das Internet PERL-Script aufgerufen werden, die aber immer interpretiert werden müssen, wobei der Interpreter nicht jedesmal geladen werden muss.
Das ist aber doch was anderes als ein Dämon, der feritg im Maschinencode läuft und auf Anfragen wartet, der muss doch nur einmal interpretiert werden und wenn der dann läuft bekommt er Daten an STDIN oder liest Daten von einem Socket (aber da kenne ich mich leider noch nicht aus).
Wenn das Script also läuft dürfte es doch eigentlich nicht mehr viel langsamer sein als C, oder? Der größte GEschwindigkeitsvorteil von C besteht ja darin das es nicht mehr interpretiert weden muss.
So ist mein Verständnis von der Sache, aber vielleicht liege ich ja auch falsch(kann durchaus sein!), dann wäre es nett wenn DU mich berichtigtst ;-)
udn 2. das es schon im RAM ist und so nicht noch von der Platte geholt werden muss.
Was ist im RAM? - Die Perlinstanz?
Der fertige Maschinecode des Scriptes. Aber was ist eine Perl-Instanz? Ein Prozess?
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?
PHP war ein Schreibfehler, meinte C ;-)
Viele Grüße
Andreas