Eigener Webserver in Delphi

[Kay]

Hallo zusammen,

bin gerade dabei, einen simplen Webserver zu entwerfen. hab' dazu die
TServerSocket Kompo verwendet.
Mit dem IE rufe ich die Seiten auf. Folgende Daten erreichen den Server:

GET /formular.html HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
Host: localhost
Connection: Keep-Alive

Das bedeutet doch, das der Klient (IE) die Datei formular.html aus dem Stammverzeichnis (welches das auch immer gerade ist) anfordert, oder?
Und nun lese ich also die gewünschte Datei von meiner Platte ein und schicke sie per SendStream an den Klient zurück ... bis hierher richtig?

Code:
ClientSocket.SendStream(TFileStream.Create(Datei, fmOpenRead or fmShareDenyWrite));

So, dann wird das Formular in der angeforderten Datei ausgefüllt und
abgeschickt. Den Webserver erreichen nun folgende Daten:

GET /test.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://localhost/formular.html
Accept-Language: de
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
Host: localhost
Content-Length: 27
Connection: Keep-Alive
Text1=Test&Button1=Absenden

Nun führe ich den PHP-Interpreter aus und lenke die Ausgabe in eine TEMP-Datei um. Die schicke ich dann wieder mit SendStream an den Klient. Gibt's noch eine bessere Variante?
Und wie erreiche ich es, dass die gesendeten Daten als Parameter an dem Skript hängen, wenn die URL im IE angezeigt wird?

Vielen Dank

Kay

[Philipp Hasenfratz]

Halihallo Kay

GET /formular.html HTTP/1.1

[...]

Das bedeutet doch, das der Klient (IE) die Datei formular.html aus dem Stammverzeichnis (welches das auch immer gerade ist) anfordert, oder?

Ja. Stammverzeichnis => DOCUMENT_ROOT Verzeichnis; wie du das auf das lokale Dateisystem
abbildest, ist dir überlassen.

Und nun lese ich also die gewünschte Datei von meiner Platte ein und schicke sie per SendStream an den Klient zurück ... bis hierher richtig?

Jein. HTTP sieht einen Response-Header vor, der durch 0D0A (zwei Bytes, hex) von der
Datei getrennt wird.

Code:
ClientSocket.SendStream(TFileStream.Create(Datei, fmOpenRead or fmShareDenyWrite));

Zuerst muss noch der Response-Header zum Client gesendet werden:

Content-Type: text/html
Status: 200 OK
Last-Modified: ...
...
[zwei Leerzeilen]
[und jetzt darfst du die Datei senden...]

GET /test.php HTTP/1.1

[...]

Content-Length: 27
Text1=Test&Button1=Absenden
Nun führe ich den PHP-Interpreter aus und lenke die Ausgabe in eine TEMP-Datei um. Die schicke ich dann wieder mit SendStream an den Klient. Gibt's noch eine bessere Variante?

Ich nehme an, dass der Output von PHP irgendwie direkt über Delphi eingelesen werden
kann? - Dann bräuchtest du keine temporäre Dateien; hast jedoch dann den Nachteil,
dass du die Ausgabe des Scriptes im Speicher hälst, was bei grossen Scripten
problematisch werden könnte.

Und wie erreiche ich es, dass die gesendeten Daten als Parameter an dem Skript hängen, wenn die URL im IE angezeigt wird?

Damit hat dein Webserver absolut nix zu tun. Was der Client anzeigt ist einzig und allein
seine Aufgabe, das kannst du nicht steuern. Versuch mal <form action="get">, du wirst
dort wohl Post stehen haben.

---

Ich würde dir empfehlen, die RCF's durchzulesen; du solltest dich an die Standards
halten, ansonsten verstehen dich die Clients nicht; und Standards zu HTTP stehen in
den RCF's, also google danach, falls du sie nicht kennst.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Kay

Nun führe ich den PHP-Interpreter aus und lenke die Ausgabe in eine TEMP-Datei um. Die schicke ich dann wieder mit SendStream an den Klient. Gibt's noch eine bessere Variante?
Und wie erreiche ich es, dass die gesendeten Daten als Parameter an dem Skript hängen, wenn die URL im IE angezeigt wird?

Kleine Korrektur von dem, was ich vorher sagte:
Hier wirds sehr problematisch! - Befasst dich mit der CGI-Schnittstelle; da wirst du
sehen, dass GET-Forumulardaten (<form ... method="get">) in der Umgebungsvariable
'QUERY_STRING' gespeichert werden und POST-Formulardaten an STDIN deines Programmes
gesendet werden (also die Standardeingabe). Die Datenübergabe von Browser an Webserver
ist einfach, aber die Datenübergabe von Webserver an PHP-Programm ist schon etwas
schwieriger. Wie gesagt, lies die Spezifikation der CGI-Schnittstelle. Und lies auch
die RCF's! - Dies gelesen zu haben ist unabdingbar, ansonsten kann man deinen Webserver
nicht brauchen.

Viele Grüsse

Philipp

[Kay]

Alles klar! Viel ndank!

MfG, Kay

[Andreas Korthaus]

Hi Philipp!

Wir hatten ja irgendwann mal über die Belsatung eines Servers von wegen Logging von HTTP-Headern diskutiert. Es müßte doch ganz eifnach möglich sein ein kleines Programmin C(++) zu schreiben, welches auf einem andern Port als 80 lauscht und alle empfangenen Daten direkt in eine Flatfile schreibt und ein transparentes 1x1 gif an den Client sendet, oder? Ich meine, letzterer HTTP-"Code" ist ja wirklich nicht schwer und sollte möglichst kurz und kann immer gleich sein.
Aber ich habe mich im Gegensatz zu Dir bisher kaum mit C++ auseinandergesetzt, ich kann zwar Dateien schreiben(nicht wirklich schwer ;-)), aber wie schwer ist es mit C++ an einem Port des Server zu lauschen und HTTP-Daten einzulesen?

Würdet Ihr auf C oder C++ setzen? Oder wäre ein gut gechriebenes PERL-Programm performanter als ein kompletter Apache?

Viele Grüße
Andreas

PS: Sorry, DU Deinem CygWin Problem untern kann ich nichts sagen, habe noch nicht viel gemacht und hatte noch kein Problem, außerdem verwende ich meist C++ unter Linux mit g++

[Philipp Hasenfratz]

Halihallo Andreas

Wir hatten ja irgendwann mal über die Belsatung eines Servers von wegen Logging von HTTP-Headern diskutiert. Es müßte doch ganz eifnach möglich sein ein kleines Programmin C(++) zu schreiben, welches auf einem andern Port als 80 lauscht und alle empfangenen Daten direkt in eine Flatfile schreibt und ein transparentes 1x1 gif an den Client sendet, oder?

Ja, das ist meiner Meinung nach wirklich einfach, nur, was hat das mit Kay zu tun?
Ich glaube, du hast mich falsch verstanden? - Ich spreche nicht von der Schwierigkeit
der Reponse, sondern von der Schwierigkeit, wie die Daten über CGI an das Script/Programm
weitergegeben werden.
Kay will ja den Output des PHP-Scriptes, um es dann an den Client weiterzuleiten.

Ich meine, letzterer HTTP-"Code" ist ja wirklich nicht schwer und sollte möglichst kurz und kann immer gleich sein.

Ich sage ja nur, dass er _nötig_ ist, wie gross er ist, spielt wirklich keine zentrale
Rolle, nur, er muss der Spezifikation genügen. Zudem wird's schon schwieriger werden,
wenn man nach HTTP/1.1 auch stay-alive Verbindungen zulässt, mit all den Konsequenzen,
Programm persistent im Speicher halten, Content-Length muss gegeben sein, ...
Und dann sollte ja auch das Caching implementiert werden (eg. Not Modified); das macht
die Response ja erst sinnvoll und erst da kriegt man die Anforderungen an einen Webserver
erst zu spüren; das lässt sich kaum in einem Tag selbstprogrammieren...

Aber ich habe mich im Gegensatz zu Dir bisher kaum mit C++ auseinandergesetzt, ich kann zwar Dateien schreiben(nicht wirklich schwer ;-)), aber wie schwer ist es mit C++ an einem Port des Server zu lauschen und HTTP-Daten einzulesen?

http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_11.html#SEC180 ;-)
"lauschen und HTTP-Daten einzulesen" ? - Er möchte einen eingenen Webserver erstellen.

Würdet Ihr auf C oder C++ setzen? Oder wäre ein gut gechriebenes PERL-Programm performanter als ein kompletter Apache?

Mit Perl bestimmt nicht, besonders, wenn der ganze Funktionsumfang des Apachen
implementiert werden würde. Für einen kleinen Statistik-Tag, der nur ein Bildchen ausgibt
und die Requests interpretiert, _kann_ (muss nicht) ein eigenes C-Programm schon die
Performance erhöhen, wobei man dann auch sehr gut Programmieren muss (preforking,
request-queue-management; also alle Requests auf z. B. 10 prefork-Prozesse verteilen,
die bereits am laufen sind o. ä.). Der Apache verwendet auch dieses Vorgehen, bei mir
habe ich es auf 50 preforked processes eingestellt, d. h. beim Starten werden 50
gleiche "Server-Prozesse" gestartet, auf die die Requests gleichmässig verteilt werden.
Ein lineares (sequentielles) Abarbeiten der Request-Queue, wie Kay das im Moment macht,
wie ich mal vermute, ist in einer Multitasking-Umgebung wenig performant.

PS: Sorry, DU Deinem CygWin Problem untern kann ich nichts sagen, habe noch nicht viel gemacht und hatte noch kein Problem, außerdem verwende ich meist C++ unter Linux mit g++

Aber kein Problem. Mit Zeit kommt Rat, irgendwann werde ich also die Lösung finden ;)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Sorry, wollte eigentlich auf ein OT schwenken ;-)

Ja, das ist meiner Meinung nach wirklich einfach, nur, was hat das mit Kay zu tun?

nichts ;-)

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.

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 ;-)

http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_11.html#SEC180

Danke!

Würdet Ihr auf C oder C++ setzen? Oder wäre ein gut gechriebenes PERL-Programm performanter als ein kompletter Apache?

Für einen kleinen Statistik-Tag, der nur ein Bildchen ausgibt
und die Requests interpretiert, _kann_ (muss nicht) ein eigenes C-Programm schon die
Performance erhöhen, wobei man dann auch sehr gut Programmieren muss (preforking,
request-queue-management; also alle Requests auf z. B. 10 prefork-Prozesse verteilen,
die bereits am laufen sind o. ä.). Der Apache verwendet auch dieses Vorgehen, bei mir
habe ich es auf 50 preforked processes eingestellt, d. h. beim Starten werden 50
gleiche "Server-Prozesse" gestartet, auf die die Requests gleichmässig verteilt werden.
Ein lineares (sequentielles) Abarbeiten der Request-Queue, wie Kay das im Moment macht,
wie ich mal vermute, ist in einer Multitasking-Umgebung wenig performant.

Danke das war es was mich interessierte ;-) Nur wenn ich das ganze mit PERL mache einst Du dann mod_perl + Apache? Aber dann habe ich ne ganze Menge Overhead für diese einfache Anwendung. 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), udn 2. das es schon im RAM ist und so nicht noch von der Platte geholt werden muss. 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!

Grüße
Andreas

[Philipp Hasenfratz]

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

[Andreas Korthaus]

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

[Philipp Hasenfratz]

Halihallo Andreas

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.

Yo, das meinte ich. Ein Super-Schlanker-Mini-Webserver ;)
Ich glaube, wir meinen das selbe.

Dieser Dämon würde ja _superschlank_  und schnell sein, theoretisch.

Yo, das einzige, was er zu tun braucht, ist: Socket auslesen (Request-Header/Content)
und gleich ins Nirvana senden (die Daten werden ja u. U. gar nicht gebraucht), dann
Datei öffnen, Pageview (oder was anderes halt) registrieren und zwei drei printf-
Anweisungen, fertig... Damit kommst du wohl sogar auf ca. 2000 Requests/s :-)

Ich habe keien AHnung wie man das macht da sman so einen Dämon-Prozess forkt(das ist sicher nicht schwer),

Mit der gleichnamigen Funktion ;)

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

Ich weiss leider nicht, wie die "Inter-Programm-Kommunikation" beim Apachen aussieht.
Aber, das schliesse ich mal aus, lauschen bestimmt nicht alle an Port 81.
Ich könnte mir vorstellen, dass es einen Request-Empfänger gibt (das Queueing-System)
und dieser dann über ein zweites Socket die Daten an die Clients (preforked processes)
verteilt; diese lauschen z. B. an Ports aufsteigend ab 19498 oder so...
Oder man verwendet UNIX-Domain-Sockets (FIFO-Queue, die die Clients auslesen können).
Oder http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_11.html#SEC225
von http://www.gnu.org/manual/glibc-2.0.6/html_chapter/libc_toc.html

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?

Ich glaube POSIX-spezifisch. POSIX definiert ein OS-Standard, der von Unix vollständig
erfüllt ist, u. a. ist eben auch fork() verfügbar. Das preforking als "Technologie"
gibt es jedoch auch auf anderen Betriebssystemen. Und ja, preforking ist auch über
Perl möglich. Alles was du brauchst, ist die Funktion fork() und die Möglichkeit
mit den anderen Prozessen zu kommunizieren (hier seien auch Semaphoren genannt, eine
weitere Möglichkeit, nur kenne ich mich damit nicht aus).

Naja, mit Prozess-Lomunikation... muss ich mich wohl erstmal auseinandersetzen, das gibt es in PHP nicht wirklich, daher kenne ich es nicht wirklich ;-)

Ich glaube ich bin jetzt lieber still und verkneif mir Kommentare
(zu PHP) :-)))
   [in letzter Zeit sind davon ja genug von meiner Seite gekommen, aber: sie sind
    ja nicht wirklich ernst gemeint ;)]

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?

Ja, doch. Ich meinte nur, dass du mit mod_perl und Apache vergl. m. IIS-Benutzern schon
sehr viel besser bedient ist :-)
Und wenn etwas im Speicher ist, muss es ja noch nicht Performance verbrauchen und
letzteres ist ja jetzt wichtig, oder? - Aber, du hast schon recht. Natürlich hast du
bei einer eigenen Lösung weniger Speicheroverhead.

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.

Ich leider auch nicht, sorry :-(

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.

Ja, der Vergleich ist etwa richtig. Zudem werden die kompilierten Code-Bäume (bereits
geparste Scripts) im Speicher behalten, was die "Kompilierung" der Scripte beschleunigt.
Und ja, es sind zwei paar Schuhe. Ich sprach davon, wie du dies mit Perl selber
"nachmachen" könntest, in Falle Apache-mod_perl hast du das ja schon gegeben.

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

Jein. Ein Perl-Daemon ist eine "Perl-Interpreter-Instanz" + "Optimierter-Code-Baum". Aber
interpretieren muss der Perlinterpreter das Script dennoch, nur nicht mehr parsen und
optimieren. Nur bei C oder einer anderen kompilierten Sprache hast du Maschinencode
vorliegen. Java ist hier so ne Mischform (Pseudomaschinen-Code).

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.

Das ist leider falsch. Genau _wegen_ dem letzteren. Das Parsen braucht natürlich schon
auch viel Zeit, aber das Interpretieren mindestens genauso viel (kommt natürlich sehr
stark auf das Programm an).

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 ;-)

Alle Angaben wie immer ohne Gewähr! :-)

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?

Ja, eine Perlinstanz ist ein Prozess. Genauer meinte ich eben den Perlinterpreter +
optimierter Codebaum. Diese zwei darf man _nie_ trennen. Ein Perlscript läuft nicht ohne
den Perlinterpreter, anders ein kompiliertes C-Programm. Es gibt keinen fertigen
Maschinencode eines Scriptes. Bei Perl gibt es höchstens einen optimierten Parse-Baum
und den Maschinencode des Perlinterpreters (ja, _der_ ist in Maschinencodem, nicht aber
das Script). Naja, ich übertreibe hier wohl etwas; was ich sagen will ist, dass ein
Script immer ein Script bleiben wird und selber, ohne Interpreter nicht lauffähig ist.
Das ist für mich der Unterschied zwischen Programm und Script.

--- optimierter Parse-Baum ---

davon hab ich ja jetzt einiges gesprochen, vielleicht noch ein zwei Worte dazu, falls
du das noch nicht weisst: Was ist ein Perl/PHP-Script? - Nix weiter als Text. Text,
der irgendwann mal was tun soll; dazu braucht es aber ein Programm, welcher diesen Text
interpretiert => Perl/PHP-Interpreter (soweit ist's ja jedem klar). Was machen nun diese
Interpreter (ich spreche jetzt vom Perl-)? - Er parsed den Text und bringt ihn in eine
interne Form (bei Perl ist das der Codebaum, eine baumartige Struktur, die reich
verzweigt ist und jedes Blatt ist irgendweine "Aktion" <- Operator [bei Perl gibt's glaub
ich etwa 300 Operatoren]). Wenn nun diese "Kompilierphase" beendet ist, fängt Perl
oben an und je nach aktuellem Kontext gehts nach links oder rechts im Baum (evtl. noch
komplizierter natürlich); aber am Anfang des Programmes kannst du den Weg noch nicht
absehen. Nun gut, ein kompiliertes Perl-Programm ist nicht Maschinencode, sondern eine
ziemlich weitverknüpfte, komplexe Datenstruktur. Eine Datenstruktur, die eben nur
zusammen mit einem Interpreter von Nutzen ist. Bei mod_perl wird diese Datenstruktur
auch im Speicher gehalten und somit fällt das langsame parsen und optimieren weg; zudem
sind die Perlinterpreter auch schon im Speicher => gar kein Festplattenzugriff mehr
nötig.

Tjo, wer (du?) sich dafür mehr interessiert, sollte sich die B-Module von Perl mal
ansehen.
Da kann man selber durch diesen ParseBaum "durchbrowsen" oder ein Perl-Script wirklich
"kompilieren" (den Parsebaum binär abbilden und dann wieder z. B. über eine Datei
einlesen und den Parsebaum überschreiben, etwas performanter, als wenn das Script im
"text/plain" vorliegt.)

---

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Andreas,

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.

wie lautet Deine exakte Aufgabenstellung? Was willst Du auswerten?

Wenn Du nur die Hits pro URL zählen willst, dann würde ich an Deiner Stelle auch noch die Dateizugriffe weglassen. Du kannst ja genauso gut die Zugriffe in einem Hash im Speicher halten und nur "bei Bedarf" einen Dump davon auf die Platte schreiben.

Viele Grüße
      Michael

[Sven Rautenberg]

Moin!

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.

Was ist die Aufgabe? Einen eigenen, ultraschlanken Webserver zu programmieren, um damit gewisse Dinge besser loggen zu können? So habe ich es jedenfalls verstanden. Dann wird weder Apache Verwendung finden, noch mod_perl. Und der Geschwindigkeitsgewinn von mod_perl wird auch gar nicht benötigt, denn er beruht schlicht darauf, das Perl-Skript einmal zu kompilieren und dann resident im Speicher zu halten. Das passiert ebenso, wenn man mit Perl einen Demon programmiert, der dann für längere Zeit laufen soll, um eben diesen ultraschlanken Server zu spielen.

Also bitte: Apache und mod_perl und sockets komplett vergessen, wenn es darum geht, das zu programmieren, was _ansonsten_ der Apache macht.

Und wenn das tatsächlich doch nicht das ist, was gewünscht war: Der Apache bietet tolle Möglichkeiten, die Logdatei frei zu konfigurieren. Da kann man im Prinzip alle Angaben des HTTP-Requests reinpacken. Und man hat nicht die Stolperfallen, die eine Eigenentwicklung eines HTTP-Servers so mit sich bringen könnte. Insbesondere ist der Apache ja wohl durchaus als schnell einzustufen, zumindest beim Ausliefern von statischem Content. Und schneller, als ein flat logfile zu schreiben, wird auch eine Eigenbaulösung nicht arbeiten können.

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

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.

Was ist die Aufgabe? Einen eigenen, ultraschlanken Webserver zu programmieren, um damit gewisse Dinge besser loggen zu können?

Genau.

So habe ich es jedenfalls verstanden. Dann wird weder Apache Verwendung finden, noch mod_perl. Und der Geschwindigkeitsgewinn von mod_perl wird auch gar nicht benötigt,

Die Frage von Andreas lautete: Welchen Faktor mod_perl bzgl. Performance ausmacht.

denn er beruht schlicht darauf, das Perl-Skript einmal zu kompilieren und dann resident im Speicher zu halten. Das passiert ebenso, wenn man mit Perl einen Demon programmiert, der dann für längere Zeit laufen soll, um eben diesen ultraschlanken Server zu spielen.

Ja, da hast du recht. Ich glaube in der "Hitze des Gefechts" hat Andreas und ich das
aus den Augen verloren ;)
Aber wir kamen eigentlich aus der C-Richtung; ein eigener Daemon auf C-Basis ist
_bestimmt_ schneller (wenn man ihn gut programmiert) als Apache.

Also bitte: Apache und mod_perl und sockets komplett vergessen, wenn es darum geht, das zu programmieren, was _ansonsten_ der Apache macht.

mod_perl vergessen, ja. C vergessen, nein.

Und wenn das tatsächlich doch nicht das ist, was gewünscht war: Der Apache bietet tolle Möglichkeiten, die Logdatei frei zu konfigurieren. Da kann man im Prinzip alle Angaben des HTTP-Requests reinpacken.

Ich mag mich an eine Diskussion erinnern, wo mir Andreas _genau_ das vorgeschlagen hat,
ich musste damals abweisen, da ich noch einige Funktionen brauchte, die der Apache nicht
hergeben kann. Fakt ist, dass Andreas das Loggin noch schneller braucht. Das sich
dies auch über mod_perl oder sonstiges nicht erreichenlässt stimmt. Aber mit C bietet
sich da schon noch einiges an.

Und man hat nicht die Stolperfallen, die eine Eigenentwicklung eines HTTP-Servers so mit sich bringen könnte. Insbesondere ist der Apache ja wohl durchaus als schnell einzustufen, zumindest beim Ausliefern von statischem Content. Und schneller, als ein flat logfile zu schreiben, wird auch eine Eigenbaulösung nicht arbeiten können.

Nun, da kenne ich den Sourcecode nicht. Aber kann man den Apachen anweisen nur
zu loggen? - Für das, was Andreas will, ist der Apache nicht hergestellt worden. Folglich
dürfte er auch nicht darauf getrimmt worden sein => deshalb bin ich der Meinung, dass
ein gutes C-Programm den Apachen in die Knie zwingt. Apache erfüllt HTTP-Spezifikationen,
verhält sich immer korrekt und versucht den Request richtig aufzulösen (also auch ein
kleiner Blick in die MainCore-Repräsentation der httpd.conf); Fakt ist, dass dies alles
für das logging im Sinne von Andreas nicht relevant ist und einer Performanceverschwenung
entspricht. Es ist jedoch zweifelhaft, ob das derart viel ausmacht, da gebe ich dir
recht => da gibt's nur eines: Testen! ;)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo zusammen!

Ja, ich kannte die Logging-Funktionen des Apachen, nur wie Philipp rictig sagt brauche ich nur 1 % des Apachen!
Und der Apache soll verhältnismäßig langsam sein was das Ausliefern von statischen Seiten angeht habe ich mir sagen lassen! IIS z.B. sei schneller, und auch eienige abndere für Linux.
Ist j auch logisch, der Apache ist ein wirklich tooles und _flexibles_ programm, nur bin ich der Meinung das Flexibilität fast immer auf Kosten von Performance geht. Alles was dynamisch geladen wird ist schlecht. Wie ich das "spezifiziert habe", ich muß nur Request annehmen und in eine Datei schreiben, und z.B. ein Bild mit 200er Statuscode zurücksenden, so wenig wie möglich. Ich brache keinen Webserver der den Request erstmal parst, analysiert, mit irgendwelchen KOnfigurationsdaten abgleicht, loggt, und dann aus dem Dateisystem eine Datei holt, dynamisch einen Header erzeugt, die Datei einliest und in den HTTP-Code einbaut. Bei mir reichen 3 Schritte. HTTP-Header entgegennehmen, in Datei schreiben und fertigen Response senden, der immer gleich ist.
Ich denke wenn sich ein Apache-programmiere hinsetzt udn so eien Server in C schreibt wird er 10 bis 100 mal schnelle rals de Apache, das _muss_ er einfach! Die Frage ist nur wie nahe ich diesem Optimum komme, heute würde ich vermutlich 10-100 mal langsamer sein als der Apache ;-)
Die Frage ist auch wie groß bei einer solchen Anwendung der Unterschied zwischen einem PERL-Dämon und einem C-Dämon ist. Die Anforderung ist ja recht klar definiert(Dämon, HTTP rein > in Datei > 1x1.gif als Response).
Wie mir Philipp erklärt hat ist das wohl doch ein Unterschied ob PERL oder C. Und wenn ich das in Perl programmiere sollte ich moglichst weitgehend auf PERL-Module verzichten, oder? Denn das ist vermutlich ziemlicher Overhead. Aber ist denn so ein "lite-httpd" _ohne_ Module überhaupt möglich?
Ist das viuelleicht vergleichbar mit dem Unterschied zw. C und C++? Bei letzterem muß man ja auch nicht mehr so viel zu Fuß machen wie beim alten C!

=> da gibt's nur eines: Testen! ;)

Nur wie? ;-) Das hatten wir ja mal, aber wie soll man bitte mehrere 1000 Requests pro Sekunde erzeugen? Mit PHP unter Windows, schaffe ich fast nichts, vielleicht ja mit C.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Und der Apache soll verhältnismäßig langsam sein was das Ausliefern von statischen Seiten angeht habe ich mir sagen lassen! IIS z.B. sei schneller, und auch eienige abndere für Linux.

Echt? IIS schneller als Apache? - Oh my god, what happens to my world... ;)

Ich denke wenn sich ein Apache-programmiere hinsetzt udn so eien Server in C schreibt wird er 10 bis 100 mal schnelle rals de Apache, das _muss_ er einfach! Die Frage ist nur wie nahe ich diesem Optimum komme, heute würde ich vermutlich 10-100 mal langsamer sein als der Apache ;-)

Nun ja, das klingt logisch, aber praktisch...? - Der Apache arbeitet eben schon sehr,
sehr schnell. Um dein C-Tag auf diese Performance zu trimmen sind eben schon etwas mehr
als 100 LOC (lines of code) notwendig. Da muss man schon mit preforking oder gar jeden
Request als neuen Prozess forken arbeiten; ansonsten, wie du sagst, wird's wohl 10-100
mal langsamer als Apache ;)

Die Frage ist auch wie groß bei einer solchen Anwendung der Unterschied zwischen einem PERL-Dämon und einem C-Dämon ist. Die Anforderung ist ja recht klar definiert(Dämon, HTTP rein > in Datei > 1x1.gif als Response).

_Dieser_ Unterschied ist meiner jetztigen Meinung nach (Sven hat mich auf den Boden
zurückgeholt ;)) schon _sehr_ hoch, sehr zu Lasten von Perl.

Wie mir Philipp erklärt hat ist das wohl doch ein Unterschied ob PERL oder C. Und wenn ich das in Perl programmiere sollte ich moglichst weitgehend auf PERL-Module verzichten, oder? Denn das ist vermutlich ziemlicher Overhead. Aber ist denn so ein "lite-httpd" _ohne_ Module überhaupt möglich?

Möglich ist es, die Module sind auch nix weiteres als Perl-Code (oftmals). Aber auch dann
wirst du niemals an die Performance von Apache kommen, da Perl eben schon 20-50x weniger
schnell ist, als ein vergleichbares C-Programm.

=> da gibt's nur eines: Testen! ;)
Nur wie? ;-) Das hatten wir ja mal, aber wie soll man bitte mehrere 1000 Requests pro Sekunde erzeugen? Mit PHP unter Windows, schaffe ich fast nichts, vielleicht ja mit C.

Tja, jetzt wirds wirklich schwierig ;-)
Da muss man wohl fast auf wirklichkeitsnahe Testsites zurückgreifen, nur, dass die wohl
kaum helfen, leider :-(

Viele Grüsse

Philipp

[Andreas Korthaus]

Halihallo Andreas

Und der Apache soll verhältnismäßig langsam sein was das Ausliefern von statischen Seiten angeht habe ich mir sagen lassen! IIS z.B. sei schneller, und auch eienige abndere für Linux.

Echt? IIS schneller als Apache? - Oh my god, what happens to my world... ;)

Muss nicht stimmen, habe es so vernommen, und zwar aus der  PHP(;-)))-Mailingliste, eine Diskussione zw. Rasmus Lerdorf(von dem ich annehme das er weiß wovon er spricht, siehe: http://www.php.net/credits.php) und mir(ich habe Ihm versucht zu erklären warum ich Apache 2 einsetzen will: http://marc.theaimsgroup.com/?t=104331770600002&r=1&w=2): http://marc.theaimsgroup.com/?l=php-install&m=104333599008887&w=2

Naja, das habe ich dann einfach mal geglaubt ;-)

Nun ja, das klingt logisch, aber praktisch...? - Der Apache arbeitet eben schon sehr,
sehr schnell. Um dein C-Tag auf diese Performance zu trimmen sind eben schon etwas mehr
als 100 LOC (lines of code) notwendig. Da muss man schon mit preforking oder gar jeden
Request als neuen Prozess forken arbeiten; ansonsten, wie du sagst, wird's wohl 10-100
mal langsamer als Apache ;)

Aber ich finds superinteressant, da man daran denke ich ne Menge lernen kann.  Hast Du eigentlich Erfahrungen wieviele % der Clients so Referer senden, denn sonst bringt mit die image-Geschicht eherzlich wenig ;-)

=> da gibt's nur eines: Testen! ;)
Nur wie? ;-) Das hatten wir ja mal, aber wie soll man bitte mehrere 1000 Requests pro Sekunde erzeugen? Mit PHP unter Windows, schaffe ich fast nichts, vielleicht ja mit C.

Tja, jetzt wirds wirklich schwierig ;-)
Da muss man wohl fast auf wirklichkeitsnahe Testsites zurückgreifen, nur, dass die wohl
kaum helfen, leider :-(

ich muss einfach mal sehen. Wenn ich das ganez im LAN mache habe ich da ganz andere Möglichkeiten, ich könnte ein kleines Tool schreiben, das auf allen 10 Client-Rechnern(Windows) verteilen und dann mal sehen. Das sind halt ganz normale Win2K Desktop PCs, alle über ethernet angeschlossen, womit schreibe ich da am besten einTool welches permanent http-Requests sendet? Am besten noch eines welches forken kann, udn wo ich keinen Interpreter und schon gar keinen Webserver für brauche, und welches gleichzeitig schnell schön ist ;-)

Wobei, windows kann gar nicht forken, oder? Wenn ich was in C++ schreibe, dann verwende ich die Cygwin Umgebung. Aber vermutlich ist das Programm dann nur unter Windows-PCs mit eben dieser Cygwin-Umgebung lauffähig, oder? Und vermutlich ist C dadurch auch erheblich langsamer, da es ja nicht wirklich OS-natives C ist.
Wenn ich ein Tool in C(++) schreiben will, welchen (freien) Compiler kann ich unter Win verwenden?

Oder ich versuche es mit VB oder sowas, das scheint mir gar nicht so schwer zu sein, oder Delphi... naja.

Oder ich suche mir eines dieser Cracker-Brute-Force Tools, aber da weißt ich jetzt nicht wonach ich suchen soll.

ODER ;-)

Ich wende meine bei try2hack frisch erforbenen "Cracker"-Kenntnisse an und such mir (frei)willige Unix-Server im Netz ;-)))

Grüße
Andreas

[Andreas Korthaus]

Hi!

Eine Idee: ich mißbrauche den Browser dafür ;-)

Und zwar generiere ich ein HTML-Dokument  mit 100.000 Bildern:

for($i=1; $i<100000;$i++) {
$str .= <<<EOT
<img src="http://localhost/x.g?i=$i">
EOT;
}

Das öffne ich im Browser und nutze so die Leistung des Browsers. Direkt probiert, auf lokalhost erreiche ich kurzzeitig 400-600 Requests pro Sekunde! Das ist doch schonmal was. Nur reicht das nicht. Ich denke der Mozilla ist nicht wirklich gut geeignet, hat sich direkt über 100MB Ram geschnappt und 80-90 % CPU. Der Apache hat sich mit 10-15 &CPU und 2-3MB RAM begnügt. Heißt das der Apache kaum Arbeit dabei hatte!
Aber welchen Browser könnte ich besser verwenden? Kennt jemand einen besonders schnellen Browser? Opera? Sollte unter Linux laufen, wobei ich das evtl im Lan probieren könnte, das ganze auf 10 Windows-Rechner verteilt, dann bekomme ich schon ne nette Rate denke ich.

Trotzdem würde ich lieber ein eigenes Tool schreiben. Auch wenn der Apache bei 500 Requests pro Sekunde nur so wenig ausgelastst ist heißt  das ja da geht noch deutlich mehr, nur kann ich das nicht alleien über  mein lokales system testen.

Aber ich habe auch mal weitergedacht. Ein Request-Header hatte 807 Byte und war wirklich so klein wie möglich.  Sagen wir mal 1 KB * 500 pro Sekunde, heißt 30 MB pro Minute - Traffic und Festplatte. An einem Tag kommt man da ja auf über 7 GB! Mit dem Resonse-Header, hieße 10 GB pro Tag, sind 300 GB pro Monat, nur für das bisschen. In der Praxis wird man da nicht hinkommen, und wenn ich davon ausgehe das der Apchebei guter Konfiguration(halt auf schnell getrimmt, was meiner nicht ist, da ist ne Menge einkompiliert und ich habe keine Ahnung von vielen Parametern), ich denke der Apache würde sicher 2000 Requests pro Sekunde schaffen, vielleicht sogar mehr, dann sind wir schon satt im Tera-Byte Bereich pro Monat. Also alles in allem, der Apache ist sicher schnell genug. Nur wenn ich direkt eine Verarbeitungs-Routine mit einbauen wollte, also nicht die Apache-Logs verwende sondern irgendwas von PERL, dann wird es wohl erheblich langsamer, nur wenn ich die Daten per Cronjob bearbeite, 8 GB, also 10 Mio Datensätze, das dauert sicher ne Zeit, kann ich überhaupt nicht einschätzen, kommt wohl drauf an was ich alles damit machen will.

Noch ein Engpass ist die Internetanbindung. Bei angenommenen 2000 Requests a 1000 Byte komme ich nichtmal mit ner 10 Mbit Leitung aus, ich kenne die Abstufungen nicht, aber so eine Anbindung ist schon ein nettes Kaliber, denn wenn ich mich nicht irre geht das nicht mehr mit SDSL, sondern braucht ne "richtige" Leitung, ich glaube das nächste ist eine 100Mbit Ethernet-Anbindung, gibt es IMHO auch zu Providern. Braucht dann aber auch eine entsprechende Infrastruktur und das ist das teure, ganz zu schweigen vom Traffic, wenn man 0,5 Cent pro MB zahlt(was IMHO sehr günstig wäre), läge man bei 2 TB bei 10.000 EUR! Naja genug der Spinnerei ;-)

Daher ist mein Interesse ab jetzt nur noch theoretischer Natur, wobei, wenn auf demselben Server andere Internetseiten laufen, wäre es schon gut einen möglichst performanten Logging-Mechanismus zu haben, alleine um die übrigen Seiten zu entlasten.

Noch ein Punkt. Wenn ich im LAN mal so einen Lasttest ausführen will, wie schaffe ich es auf 10 Rechnern(WIn2K) die Browser gleichzeitig dazu zu bewegen, eine Seite aufzurufen?

Mein Idee wäre einen geplanten Task auszuführen und zwar eine Batch-Datei mit:
mozilla http://192.168.0.1/force.html

Nur wie bekomme ich die Zeiten gleich? Kann ich Windows auch über einen Zeitserver synchronisieren?
Und wie ist das mit anderen, schnelleren Browsern, kennt Iht Browser die man genau so mit einer Adresse starten kann?

Naja, Fragen über Fragen... ich find sowas irgendwie immer interessant ;-) Und das meiste lerne/bemerke ich während ich ein Posting schreibe ;-)

Grüße
Andreas

PS: Sorry wegen meiner ständigen Rechtschreibfehler, ich bin so faul...

[Philipp Hasenfratz]

Halihallo Andreas

sorry, musste The Ring sehen gehen ;)

Eine Idee: ich mißbrauche den Browser dafür ;-)

Och, der Arme... Das Lasttier Browser...

Und zwar generiere ich ein HTML-Dokument  mit 100.000 Bildern:
for($i=1; $i<100000;$i++) {
$str .= <<<EOT
<img src="http://localhost/x.g?i=$i">
EOT;
}

Hast du bemerkt, da hast du das selbe Problem, was dich auch vom Apachen wegbringt!
Der Browser ist ebenfalls nicht für diese "Anwendung" zu gebrauchen, da auch er nicht
für das Ziel optimiert ist. Ich bin mir sicher, dass du mit einem prefork C-Script
noch mehr rausholen könntest... Nur, und das wirst du dir wohl auch überlegt haben,
ist dies die einfachste Testmethode, wenn man sich nicht gleich an C wendet, das stimmt.
Zudem ist der Fehler dieser Methode doch schon sehr hoch... Um genau zu messen müsstest
du genau wissen, was deine Programme machen, das kannst du beim Browser nur nicht.

Das öffne ich im Browser und nutze so die Leistung des Browsers. Direkt probiert, auf lokalhost erreiche ich kurzzeitig 400-600 Requests pro Sekunde! Das ist doch schonmal was. Nur reicht das nicht. Ich denke der Mozilla ist nicht wirklich gut geeignet, hat sich direkt über 100MB Ram geschnappt und 80-90 % CPU. Der Apache hat sich mit 10-15 &CPU und 2-3MB RAM begnügt. Heißt das der Apache kaum Arbeit dabei hatte!

Tja, da haben wir's, du hast die Geschwindigkeit des Browsers gemessen, nicht die des
Apachen ;)

Aber welchen Browser könnte ich besser verwenden?

lynx? - Vielleicht ist der etwas schneller... Oder aber gar keinen, da wirklich nicht
sehr für das Problem geeignet.

Kennt jemand einen besonders schnellen Browser? Opera? Sollte unter Linux laufen, wobei ich das evtl im Lan probieren könnte, das ganze auf 10 Windows-Rechner verteilt, dann bekomme ich schon ne nette Rate denke ich.

IMHO die einzige Lösung, die Request-Starter dürfen sowieso nicht auf demselben Rechner
sein, da dies das Messergebnis SEHR stark beeinflusst. Das Messergebnis ist auf keinen
Fall signifikant, wenn beide Anwendungen auf demselben Rechner laufen.

Aber ich habe auch mal weitergedacht. Ein Request-Header hatte 807 Byte und war wirklich so klein wie möglich.  Sagen wir mal 1 KB * 500 pro Sekunde, heißt 30 MB pro Minute - Traffic und Festplatte. An einem Tag kommt man da ja auf über 7 GB! Mit dem Resonse-Header, hieße 10 GB pro Tag, sind 300 GB pro Monat, nur für das bisschen. In der Praxis wird man da nicht hinkommen, und wenn ich davon ausgehe das der Apchebei guter Konfiguration(halt auf schnell getrimmt, was meiner nicht ist, da ist ne Menge einkompiliert und ich habe keine Ahnung von vielen Parametern), ich denke der Apache würde sicher 2000 Requests pro Sekunde schaffen, vielleicht sogar mehr, dann sind wir schon satt im Tera-Byte Bereich pro Monat. Also alles in allem, der Apache ist sicher schnell genug. Nur wenn ich direkt eine Verarbeitungs-Routine mit einbauen wollte, also nicht die Apache-Logs verwende sondern irgendwas von PERL, dann wird es wohl erheblich langsamer, nur wenn ich die Daten per Cronjob bearbeite, 8 GB, also 10 Mio Datensätze, das dauert sicher ne Zeit, kann ich überhaupt nicht einschätzen, kommt wohl drauf an was ich alles damit machen will.

Ein anderer wichtiger Gedanke! - Daran hatte ich gar nicht gedacht ;)

Noch ein Engpass ist die Internetanbindung. Bei angenommenen 2000 Requests a 1000 Byte komme ich nichtmal mit ner 10 Mbit Leitung aus, ich kenne die Abstufungen nicht, aber so eine Anbindung ist schon ein nettes Kaliber, denn wenn ich mich nicht irre geht das nicht mehr mit SDSL, sondern braucht ne "richtige" Leitung, ich glaube das nächste ist eine 100Mbit Ethernet-Anbindung, gibt es IMHO auch zu Providern. Braucht dann aber auch eine entsprechende Infrastruktur und das ist das teure, ganz zu schweigen vom Traffic, wenn man 0,5 Cent pro MB zahlt(was IMHO sehr günstig wäre), läge man bei 2 TB bei 10.000 EUR! Naja genug der Spinnerei ;-)

s. oben ;)

Noch ein Punkt. Wenn ich im LAN mal so einen Lasttest ausführen will, wie schaffe ich es auf 10 Rechnern(WIn2K) die Browser gleichzeitig dazu zu bewegen, eine Seite aufzurufen?

Ein Prozess, der die "Request-Starter-Prozesse" auf den anderen Rechnern startet. So,
wie wir dies damals gemacht haben.

Nur wie bekomme ich die Zeiten gleich? Kann ich Windows auch über einen Zeitserver synchronisieren?

Wahrscheinlich schon, aber warum nicht so, wie wir dies damals gemacht haben, ist IMHO
schnell umzusetzen und erzielt akzeptable Ergebnisse (100ms Verzögerung, is OK, oder?).

Naja, Fragen über Fragen... ich find sowas irgendwie immer interessant ;-) Und das meiste lerne/bemerke ich während ich ein Posting schreibe ;-)

Genau!

PS: Sorry wegen meiner ständigen Rechtschreibfehler, ich bin so faul...

Das ist ein FORUM, solange du so schreibst, dass man es versteht (und dem ist natürlich
so) ;)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

sorry, musste The Ring sehen gehen ;)

naja, diesmal lasse ich es noch durchgehen ;-)

Und zwar generiere ich ein HTML-Dokument  mit 100.000 Bildern:
for($i=1; $i<100000;$i++) {
$str .= <<<EOT
<img src="http://localhost/x.g?i=$i">
EOT;
}

Hast du bemerkt, da hast du das selbe Problem, was dich auch vom Apachen wegbringt!

Nein. Mit obigem Code generiere ich ein html-Dokument, das speicher eich ab und rufe es im Browser über den Apachen auf. Und wegen ?i=$i wird für jedes Bild ein eigener Request gesendet und vom Apachen geloggt, ich erhalte also Einträge in meiner Access.log, in der ich sehr schön die Requests pro Sekunde ablesen kann. Und da der Apacher sich weniger als 15% der zur Verfügung stehenden Performance genehmigt, und der Mozilla den ganzen Rest, gehe ich davon aus das der Apache noch deutlich leistungsfähiger ist, nämlich in dem Fall das der  Mozilla nicht auf dem gleichen Rechner läuft, sondern die Requests von der Netzwerkkarte kommen, die brucht kaum Performance also kann der Apache sich bedienen.

Der Browser ist ebenfalls nicht für diese "Anwendung" zu gebrauchen, da auch er nicht
für das Ziel optimiert ist. Ich bin mir sicher, dass du mit einem prefork C-Script
noch mehr rausholen könntest...

Ganz sicher sogar, nur bedenke das ich mit der Methode fast 10 mal so viele Request bekommen habe wie mit unseren Perl-Versuchen damals, wobei das Perl-Script nucht gegen localhost ging, was das ganez aber durch fork nicht verlangsamen sollte, oder?

Nur, und das wirst du dir wohl auch überlegt haben,
ist dies die einfachste Testmethode, wenn man sich nicht gleich an C wendet, das stimmt.
Zudem ist der Fehler dieser Methode doch schon sehr hoch... Um genau zu messen müsstest
du genau wissen, was deine Programme machen, das kannst du beim Browser nur nicht.

Wieso? Der Broswer läd erstmal dei html-Seite, und dann stehen da 100.000 Bilder mit verschiedenen Quelen drin(?i=$i), die alle per HTTP-Request runterheladn wrden müssen. Der Apache loggt dann jeden Request mit Sekundengenauer Zeitangabe. Aber hast schon recht, ich muß das über das LAN machen um etwas realistischere Daten zu bekommen.
Über das Internet kann ich schlecht was machen wegen 16KB upsteam,das sind gerade mal 16 Requests pro Sekunde :( Jetzte verstehe ich auch wieso das von meinem Rechner damals so langsam war.... ;-)

Der Apache hat sich mit 10-15 &CPU und 2-3MB RAM begnügt. Heißt das der Apache kaum Arbeit dabei hatte!

Tja, da haben wir's, du hast die Geschwindigkeit des Browsers gemessen, nicht die des
Apachen ;)

Wieso? Ich habe in den acccess.logs gemessen. Der Engpass war die Performance des Browsers,daher schloss ich daraus das der Apache mehr schafft, wieviel muß ich im LAN testen.

Aber welchen Browser könnte ich besser verwenden?

lynx? - Vielleicht ist der etwas schneller... Oder aber gar keinen, da wirklich nicht
sehr für das Problem geeignet.

Zumal lynx keie Bilder darstellen kann, udn so vermutlich <img src=... ignoriert, zumindest keien Request sendet, warum auch wenn er es nicht darstellen kann. Außerdem suche ich was für Windows. Wobei, ich könnte einfach eien .url Datei oder sowas anlegen, das ist glaube ich ein bookmark, den der Internet-Explorer direkt öffent, ich vermute das der IE besonder schnell ist da er sehr vieel Recourcen von Win nutzen wird!

Kennt jemand einen besonders schnellen Browser? Opera? Sollte unter Linux laufen, wobei ich das evtl im Lan probieren könnte, das ganze auf 10 Windows-Rechner verteilt, dann bekomme ich schon ne nette Rate denke ich.

IMHO die einzige Lösung, die Request-Starter dürfen sowieso nicht auf demselben Rechner
sein, da dies das Messergebnis SEHR stark beeinflusst.

In wiefern? Der Apache wurde nur duch den Mozilla ausgebremst, um umgekehrt ein wenig.

Das Messergebnis ist auf keinen
Fall signifikant, wenn beide Anwendungen auf demselben Rechner laufen.

Stimmt, aber es sagt mir das locker übe 1000 Requests drin sind. Eien Maxumalwert habe ichdamit sicher nicht gefunden, aber das habe ich ja von Anfang an gesgagt da der Mozilla den großen Teil der Performance gefressen hat ;-)

Noch ein Punkt. Wenn ich im LAN mal so einen Lasttest ausführen will, wie schaffe ich es auf 10 Rechnern(WIn2K) die Browser gleichzeitig dazu zu bewegen, eine Seite aufzurufen?

Ein Prozess, der die "Request-Starter-Prozesse" auf den anderen Rechnern startet.

Und im LAN? Da hat nicht jeder Rechner eine Webserver. Wi eereiche ich denn dei Scritpe oder Kommandozeile auf den verschidenen Rechnern(Windows!)?

So,
wie wir dies damals gemacht haben.

Wurden die Scrpte automatisch gestartet? Wie wurde das genau initiiert? Haben die an einem Socket gelauscht? Kan ich mir nicht vorstellen, da macht kein Provider sicher nicht mit ;-)

Wahrscheinlich schon, aber warum nicht so, wie wir dies damals gemacht haben, ist IMHO
schnell umzusetzen und erzielt akzeptable Ergebnisse (100ms Verzögerung, is OK, oder?).

Ich muß0 mir die Scripte nochmal angucken, weiß gerade nicht mehr mwie das gemacht wurde, mit dem Teil des Scripte habe ich mich auch nicht beschäftigt. Nur, bedenke das es alles windows-maschinen sind, dei alle kein Perl installiert haben, aber das kann man ja ändern, nur damit ist es nicht mehr ganz so einfach ;-) Das ist ja der Vorteil von C, das läfut so!

PS: Sorry wegen meiner ständigen Rechtschreibfehler, ich bin so faul...

Das ist ein FORUM, solange du so schreibst, dass man es versteht (und dem ist natürlich
so) ;)

Trotzdem ärgert es mich im nachhinein immer, und ich bin fast der einzige der so schreibt, man könnte meinen ich sei Legasteniker ;-)

Vielen Dank für Deine wie immer interessanten und ausführlichen Antworten, und viele Grüße

Andreas

[Philipp Hasenfratz]

Halihallo Andreas

sorry, musste The Ring sehen gehen ;)
naja, diesmal lasse ich es noch durchgehen ;-)

Hu, ha, mit blauem Auge nochmals davongekommen...

Hast du bemerkt, da hast du das selbe Problem, was dich auch vom Apachen wegbringt!
Nein. Mit obigem Code generiere ich ein html-Dokument, das speicher eich ab und rufe es im Browser über den Apachen auf. Und wegen ?i=$i wird für jedes Bild ein eigener Request gesendet und vom Apachen geloggt, ich erhalte also Einträge in meiner Access.log, in der ich sehr schön die Requests pro Sekunde ablesen kann. Und da der Apacher sich weniger als 15% der zur Verfügung stehenden Performance genehmigt, und der Mozilla den ganzen Rest, gehe ich davon aus das der Apache noch deutlich leistungsfähiger ist, nämlich in dem Fall das der  Mozilla nicht auf dem gleichen Rechner läuft, sondern die Requests von der Netzwerkkarte kommen, die brucht kaum Performance also kann der Apache sich bedienen.

Ja, ich spreche ja von der APerformance des Browsers. Eben, du kannst ja gar keine
relevanten Daten aus diesem Test ziehen, wenn der Browser die ganze Zeit arbeitet, du
willst ja, dass der Apache zu schwitzen beginnt ;)
Gut, eines haben wir aus dieser Testserie gelernt: Der Apache ist gut, sehr gut! ;)
try2hack.nl: Bringt Andreas Apachen das Schwitzen bei ;)

Der Browser ist ebenfalls nicht für diese "Anwendung" zu gebrauchen, da auch er nicht
für das Ziel optimiert ist. Ich bin mir sicher, dass du mit einem prefork C-Script
noch mehr rausholen könntest...
Ganz sicher sogar, nur bedenke das ich mit der Methode fast 10 mal so viele Request bekommen habe wie mit unseren Perl-Versuchen damals

Stimmt. Da siehste, wie langsam Perl ist ;)

wobei das Perl-Script nucht gegen localhost ging, was das ganez aber durch fork nicht verlangsamen sollte, oder?

fork() braucht schon ein bissle Performance, aber nicht soviel, dass es ins Gewicht
fallen sollte (ich meine, die fork-Variante hat ja einiges an Performance, sprich
Requests/s gebracht). Aber vielleicht ist das Multithreading der Browser (ich nehme mal
an, dass es dort über Threads gemacht wird) etwas besser. Dort muss nicht alles vom
Programm abgebildet werden (Filehandles, Sockets, Memory, Prozessinformation, ...).

Nur, und das wirst du dir wohl auch überlegt haben,
ist dies die einfachste Testmethode, wenn man sich nicht gleich an C wendet, das stimmt.
Zudem ist der Fehler dieser Methode doch schon sehr hoch... Um genau zu messen müsstest
du genau wissen, was deine Programme machen, das kannst du beim Browser nur nicht.
Wieso? Der Broswer läd erstmal dei html-Seite, und dann stehen da 100.000 Bilder mit verschiedenen Quelen drin(?i=$i), die alle per HTTP-Request runterheladn wrden müssen. Der Apache loggt dann jeden Request mit Sekundengenauer Zeitangabe. Aber hast schon recht, ich muß das über das LAN machen um etwas realistischere Daten zu bekommen.

Ja, so gesehen hast du recht. Ich dachte nur, wenn du die Performance testen willst,
musst du beide Programme gut kennen um wirklich gute Messungen durchzuführen. Du musst
die Schwachpunkte der Programme kennen (eg. eben, dass Browser erst HTML-Datei parsen
muss und dann jede Ressource einlädt, zeitgleich auch schonmal versucht die Page zu
rendern...).

Über das Internet kann ich schlecht was machen wegen 16KB upsteam,das sind gerade mal 16 Requests pro Sekunde :( Jetzte verstehe ich auch wieso das von meinem Rechner damals so langsam war.... ;-)

Das erklärt natürlich einiges ;)

Der Apache hat sich mit 10-15 &CPU und 2-3MB RAM begnügt. Heißt das der Apache kaum Arbeit dabei hatte!

Tja, da haben wir's, du hast die Geschwindigkeit des Browsers gemessen, nicht die des
Apachen ;)
Wieso? Ich habe in den acccess.logs gemessen. Der Engpass war die Performance des Browsers,daher schloss ich daraus das der Apache mehr schafft, wieviel muß ich im LAN testen.

Wiederspreche ich gar nicht. Aber du hast dennoch gemessen, wieviele Requests/s der
Browser schafft, nicht der Apache. Da ersterer fast alle CPU-Zeit gefressen hat, folgerst
du richtig, dass der Apache mehr schafft. Aber _gemessen_ hast du die Performance des
Browsers und der hat bei dir kurzzeitig 300-400 Requests/s geschafft...

Aber welchen Browser könnte ich besser verwenden?

lynx? - Vielleicht ist der etwas schneller... Oder aber gar keinen, da wirklich nicht
sehr für das Problem geeignet.
Zumal lynx keie Bilder darstellen kann, udn so vermutlich <img src=... ignoriert, zumindest keien Request sendet, warum auch wenn er es nicht darstellen kann.

Äm... ja... ich sollte schlafen gehen ;)

Kennt jemand einen besonders schnellen Browser? Opera? Sollte unter Linux laufen, wobei ich das evtl im Lan probieren könnte, das ganze auf 10 Windows-Rechner verteilt, dann bekomme ich schon ne nette Rate denke ich.

IMHO die einzige Lösung, die Request-Starter dürfen sowieso nicht auf demselben Rechner
sein, da dies das Messergebnis SEHR stark beeinflusst.
In wiefern? Der Apache wurde nur duch den Mozilla ausgebremst, um umgekehrt ein wenig.

Aber Andreas, du möchtest den Apachen testen, also muss der isoliert sein, egal ob viel
oder wenig von anderen Prozessen beeinflusst, es verzerrt das Ergebnis und das soll
möglichst ausgeschlossen werden. Wenn du da ein Browser nebenherbetreibst, der 90% der
CPU frisst, wie willst du denn eine Aussage über die Performance des Apachen machen???

Das Messergebnis ist auf keinen
Fall signifikant, wenn beide Anwendungen auf demselben Rechner laufen.
Stimmt, aber es sagt mir das locker übe 1000 Requests drin sind. Eien Maxumalwert habe ichdamit sicher nicht gefunden, aber das habe ich ja von Anfang an gesgagt da der Mozilla den großen Teil der Performance gefressen hat ;-)

Mir scheint, du möchtest einfach eine möglichst hohe Zahl erreichen, ungeachtet dessen,
ob sie relevant ist... => Zu messende Grösse auf einen Rechner, Messhilfen
(Requestoren*g*) auf einen/mehrere andere(n).

Noch ein Punkt. Wenn ich im LAN mal so einen Lasttest ausführen will, wie schaffe ich es auf 10 Rechnern(WIn2K) die Browser gleichzeitig dazu zu bewegen, eine Seite aufzurufen?

Ein Prozess, der die "Request-Starter-Prozesse" auf den anderen Rechnern startet.

Und im LAN? Da hat nicht jeder Rechner eine Webserver. Wi eereiche ich denn dei Scritpe oder Kommandozeile auf den verschidenen Rechnern(Windows!)?

Ein Script, dass an einem Port lauscht und einfach wartet. Dieses Script auf allen
Rechnern starten und dann von einem Rechner aus, ein anderes Script starten, dass diese
Ports anpingt, dann sollen alle lauschenden Scripte gestartet werden und dann sollen die
Requests losdüsen. So erreichst du ein ziemlich zeitnahes, synchrones starten.

So,
wie wir dies damals gemacht haben.
Wurden die Scrpte automatisch gestartet? Wie wurde das genau initiiert? Haben die an einem Socket gelauscht? Kan ich mir nicht vorstellen, da macht kein Provider sicher nicht mit ;-)

Tja, wir haben sie über'n Browser gestartet und dann haben sie sich vermehrt und
losgemüllt.

PS: Sorry wegen meiner ständigen Rechtschreibfehler, ich bin so faul...

Das ist ein FORUM, solange du so schreibst, dass man es versteht (und dem ist natürlich
so) ;)
Trotzdem ärgert es mich im nachhinein immer, und ich bin fast der einzige der so schreibt, man könnte meinen ich sei Legasteniker ;-)

Nun, ich habe es mir so angewöhnt, dass ich bereits beim erstmaligen schreiben darauf
achte, so muss ich nacher nicht immer nochmals alles durchlesen. Wenn man sich das
erstmal verinnerlicht hat, gehts schon sehr viel besser.

Vielen Dank für Deine wie immer interessanten und ausführlichen Antworten, und viele

... und das selbe zurück! - Ist auch für mich immer interessant (und ausführlich sind
deine Antworten auch *g*)! - Ich glaube, wir verstehen einander zu fordern und dann
kann man am meisten lernen.

Viele Grüsse

Philipp

[Andreas Korthaus]

hi!

Ja, ich spreche ja von der APerformance des Browsers. Eben, du kannst ja gar keine
relevanten Daten aus diesem Test ziehen, wenn der Browser die ganze Zeit arbeitet, du
willst ja, dass der Apache zu schwitzen beginnt ;)
Gut, eines haben wir aus dieser Testserie gelernt: Der Apache ist gut, sehr gut! ;)

Genau das ist auch mein Fazit, und es war mir ganz bewußt das diese Messung des Apachen nicht wirklich gut, ist, die Sache ist nur die
das ich eingesehen habe, dass die Performance des Apachen vollkommen ausreichend ist. Meine Messdaten sind _sehr_ ungünstig, unter optimalen Bedingungen(keine andere Last, optimierte Parameter, weniger Module...) wird der Apache so ziemlich allem Standhalten was ich mir an Szenarien vorstellen könnte, denn selbst 1000 Requests/Sekunde werde ich meinen Lebtag nirgendwo erreichen, selbst Internetseiten mit 1 Millionen Requsts pro Tag würden selbst zu Stoßzeiten keine wirklichen Probleme bereiten. Der Test hat mir also ein Ergebnis geliefert, welches auf alle Fälle ausreichend ist, und gleichzeitig unter sehr schlechten Bedingungen stattgefunden hat.
Nächste Woche mache ich trotzdem mal ein paar Tests, mal gucken ob ich den Apachen in die Knie zwingen kann. Ich werde mal so ein paar richtig nette Benchmarks fahren, ich werde Apache Win/Linux vergleichen, Apache 1/2, und das alles mit einem solchen einfachen Log-Request, einem durchschnittlichen statischen html-Dokument, einem PHP-Script und einem PERL-Script, vielleicht vergleiche ich auch noch die Modul und CGI Varianten, mal schaun ;-) das alles interessiert mich nämlich mal ;-)

Hast Du ideen für ein "tyisches" Script? In ner Schleife bis 1000 Zählen oder sowas? Vielleicht noch die RegEx Engine anwefen... mal sehen.

try2hack.nl: Bringt Andreas Apachen das Schwitzen bei ;)

*ggg*

Stimmt. Da siehste, wie langsam Perl ist ;)

aber um den Faktor? Nö, ich bin absolut dämlich heute, das forken bringt gar nichts, oder nicht viel, denn wenn die Leitung nur 16KB schaft dann schafft sei nur 16 KB, da bringt alles programmieren nichts, über die Leitung kann nicht mehr kommen als die Bandbreite hergibt. Also doch nicht so schlim mit PERL(bzw. kann ich keine Aussage dazu machen) ;-) ich kann es ja auch mal mit PERL auf localhost probieren ;-)

Aber _gemessen_ hast du die Performance des
Browsers und der hat bei dir kurzzeitig 300-400 Requests/s geschafft...

_kurzzeitig_ habe ich fast 1000 Requests/s geschafft, 500 war der Schnitt, denn hinterher wird es sehr langsam wenn der Browser probiert  50.000 und mehr Bilder darzustellen... Vielleicht sollte man das mit Javascript machen! Geht das überhaupt? Wäre ja ein Witz wenn ich  mit Javascript einen Server abschießen könnte!

Ein Script, dass an einem Port lauscht und einfach wartet. Dieses Script auf allen
Rechnern starten und dann von einem Rechner aus, ein anderes Script starten, dass diese
Ports anpingt, dann sollen alle lauschenden Scripte gestartet werden und dann sollen die
Requests losdüsen. So erreichst du ein ziemlich zeitnahes, synchrones starten.

Was für ein Script, die Rechner haben wie gesagt keinen PERL-interpreter, und das batch sowas kann wage ich zu bezweifeln ;-)

Vielen Dank für Deine wie immer interessanten und ausführlichen Antworten, und viele

... und das selbe zurück! - Ist auch für mich immer interessant (und ausführlich sind
deine Antworten auch *g*)! - Ich glaube, wir verstehen einander zu fordern und dann
kann man am meisten lernen.

Sehe ich genauso!

In diesem Sinne -

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Nächste Woche mache ich trotzdem mal ein paar Tests, mal gucken ob ich den Apachen in die Knie zwingen kann. Ich werde mal so ein paar richtig nette Benchmarks fahren, ich werde Apache Win/Linux vergleichen, Apache 1/2, und das alles mit einem solchen einfachen Log-Request, einem durchschnittlichen statischen html-Dokument, einem PHP-Script und einem PERL-Script, vielleicht vergleiche ich auch noch die Modul und CGI Varianten, mal schaun ;-) das alles interessiert mich nämlich mal ;-)

Wenn's möglich ist, täten mich die Benchmarks interessieren. Falls du dazukommst und
nicht der Forums-Droge (Level10) verfällst ;-)

Hast Du ideen für ein "tyisches" Script? In ner Schleife bis 1000 Zählen oder sowas? Vielleicht noch die RegEx Engine anwefen... mal sehen.

Ein typisches Script für was? - Um die Requests zu starten? - Warum RegExp?
Habe IMHO grad keines zur Hand, aber wenn du etwas spezifizierst, steuere ich meinen
Beitrag zum Bench dazu.

Stimmt. Da siehste, wie langsam Perl ist ;)
aber um den Faktor? Nö, ich bin absolut dämlich heute, das forken bringt gar nichts, oder nicht viel, denn wenn die Leitung nur 16KB schaft dann schafft sei nur 16 KB, da bringt alles programmieren nichts, über die Leitung kann nicht mehr kommen als die Bandbreite hergibt. Also doch nicht so schlim mit PERL(bzw. kann ich keine Aussage dazu machen) ;-) ich kann es ja auch mal mit PERL auf localhost probieren ;-)

Ja, die Bandbreite ist bei dir übers INET das begrenzende... An die 16KB kommst du auch
mit einem Prozess, der sequentiell alle Requests versendet... localhost ist IMHO die
einzige Möglichkeit (oder eben übers lokale Netzwerk). Magst dich noch erinnern? -
Matti hat's auf ca. 200-400 Requests/s geschafft.

Aber _gemessen_ hast du die Performance des
Browsers und der hat bei dir kurzzeitig 300-400 Requests/s geschafft...
_kurzzeitig_ habe ich fast 1000 Requests/s geschafft, 500 war der Schnitt, denn hinterher wird es sehr langsam wenn der Browser probiert  50.000 und mehr Bilder darzustellen... Vielleicht sollte man das mit Javascript machen! Geht das überhaupt? Wäre ja ein Witz wenn ich  mit Javascript einen Server abschießen könnte!

Kein Witz, ich habe sogar mit JS den Computer aufgehängt... Ein waschechter Javascript-
Virus :-)
Natürlich geht das auch mit JavaScript, jedoch wird das um einiges langsamer sein, als
wenn du mit PHP die HTML Seite ausgibst; desweiteren kannst du über JS nicht die
Darstellung verhindern => kein Performancegewinn. Du kannst jedoch versuchen, alle in
ein hidden-div zu stecken, dann lädt der Browser die Bilder hoffentlich trotzdem,
versucht sie jedoch nicht darzustellen.

Ein Script, dass an einem Port lauscht und einfach wartet. Dieses Script auf allen
Rechnern starten und dann von einem Rechner aus, ein anderes Script starten, dass diese
Ports anpingt, dann sollen alle lauschenden Scripte gestartet werden und dann sollen die
Requests losdüsen. So erreichst du ein ziemlich zeitnahes, synchrones starten.
Was für ein Script, die Rechner haben wie gesagt keinen PERL-interpreter, und das batch sowas kann wage ich zu bezweifeln ;-)

Ja, da hast du recht. Ich glaube aber kaum, dass du um eine Programmiersprache
herumkommst bzw. nur mit Mehraufwand, der nicht sein müsste. Klar, du müsstest die
Uhrzeiten synchronisieren, könntest einen zeitgesteuerten Task starten und und und,
aber wäre es nicht einfacher PHP oder Perl zu installieren?

In diesem Sinne -

• try2hack.nl :-)

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Philipp,

Ganz sicher sogar, nur bedenke das ich mit der Methode fast 10 mal so viele Request bekommen habe wie mit unseren Perl-Versuchen damals
Stimmt. Da siehste, wie langsam Perl ist ;)

Du siehst nur, daß der Browser seine Requests parallelisiert.
Starte des Perl-Programm 20 mal parallel, und die Sache sieht gleich ganz anders aus ...

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

Ganz sicher sogar, nur bedenke das ich mit der Methode fast 10 mal so viele Request bekommen habe wie mit unseren Perl-Versuchen damals
Stimmt. Da siehste, wie langsam Perl ist ;)

Du siehst nur, daß der Browser seine Requests parallelisiert.
Starte des Perl-Programm 20 mal parallel, und die Sache sieht gleich ganz anders aus ...

Das PERL-Programm(hatten philipp und ich mal vor einiger Zeit mal laufen lassen um die Performance seines Webservers(beim Provider) zu testen) hat doch FORK verwendet um sich zu kopieren und parallel laufen zu lassen. Und außerdem ging das PERL-Scritrp über die DSL-Leitung und der Browser-Request über localhost, ist also nicht wirklich vergleichbar ;-)

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Und da der Apacher sich weniger als 15% der zur Verfügung stehenden Performance genehmigt,
und der Mozilla den ganzen Rest,

15% wovon? Welche Ressource war denn überhaupt die knappe? (CPU, RAM, Bus-Zugriffe, ...)
Und welche relativen Prioritäten besaßen die beiden Prozesse auf derselben Maschine?

gehe ich davon aus das der Apache noch deutlich leistungsfähiger ist, nämlich in dem Fall das
der Mozilla nicht auf dem gleichen Rechner läuft, sondern die Requests von der Netzwerkkarte
kommen, die brucht kaum Performance also kann der Apache sich bedienen.

Probiere es aus - trenne Client und Server auf separate Maschinen und laß das Programm nochmal laufen. Deinen bisherigen Test auf demselben Rechner halte ich nicht für aussagekräftig.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Andreas,

Eine Idee: ich mißbrauche den Browser dafür ;-)
Aber welchen Browser könnte ich besser verwenden? Kennt jemand einen besonders schnellen Browser?

such mal nach "apachebench" - es gibt spezielle Benchmark-Programme für Webserver.

Alternativ kannst Du mal hier im Archiv suchen - ich habe hier vor etwa zwei Jahren (?) ein Programm gezeigt bekommen, das ganz primitiv und sehr schnell große Mengen von HTTP-Requests in ein socket feuert (wir haben das auch selbst mit Erfolg hier im Büro eingesetzt ... der entsprechende Kollege ist allerdings gerade in Urlaub).

Aber ich habe auch mal weitergedacht. Ein Request-Header hatte 807 Byte und war wirklich so klein wie möglich.

"Kleine" HTTP-Request-Header sind nach meiner Erfahrung um die 200 Byte groß, wenn man seinen Browser sinnvoll konfiguriert. 807 Byte fände ich gigantisch - was steht denn da alles drin?

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

such mal nach "apachebench" - es gibt spezielle Benchmark-Programme für Webserver.

Guter Tipp ;-)

Alternativ kannst Du mal hier im Archiv suchen - ich habe hier vor etwa zwei Jahren (?) ein Programm gezeigt bekommen, das ganz primitiv und sehr schnell große Mengen von HTTP-Requests in ein socket feuert (wir haben das auch selbst mit Erfolg hier im Büro eingesetzt ... der entsprechende Kollege ist allerdings gerade in Urlaub).

Werde ich tun!

Aber ich habe auch mal weitergedacht. Ein Request-Header hatte 807 Byte und war wirklich so klein wie möglich.

"Kleine" HTTP-Request-Header sind nach meiner Erfahrung um die 200 Byte groß, wenn man seinen Browser sinnvoll konfiguriert.

worauf ich in der Realität keinen Einfluss habe!

807 Byte fände ich gigantisch - was steht denn da alles drin?

Hm, kann ich im Moment auch nicht nachvolziehen, habe meinen Mozilla Gemessen und das sind "nur" 500, die Accept-Zeile ist ziemlich lang. Bei meinen Tests damals wurde eigentlich nur noch ein Referer mitgeschickt und sonst wüßte ich nicht mehr was. Muß bei Gelegenheit nochmal nachgucken, aber 807 war der Wert der in den Logs eingetragen wurde, vielleicht war da aber auch schon der Response mit drin?!

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Und der Apache soll verhältnismäßig langsam sein was das Ausliefern von statischen Seiten angeht habe ich mir sagen lassen! IIS z.B. sei schneller, und auch eienige abndere für Linux.

Echt? IIS schneller als Apache? - Oh my god, what happens to my world... ;)
Muss nicht stimmen, habe es so vernommen, und zwar aus der  PHP(;-)))-Mailingliste, eine Diskussione zw. Rasmus Lerdorf(von dem ich annehme das er weiß wovon er spricht, siehe: http://www.php.net/credits.php) und mir(ich habe Ihm versucht zu erklären warum ich Apache 2 einsetzen will: http://marc.theaimsgroup.com/?t=104331770600002&r=1&w=2): http://marc.theaimsgroup.com/?l=php-install&m=104333599008887&w=2

Danke! - Interessant... (und erschreckend :-))

Naja, das habe ich dann einfach mal geglaubt ;-)

Ich formuliere vorsichtiger: Ich nehme es zur Kenntnis :-)

Nun ja, das klingt logisch, aber praktisch...? - Der Apache arbeitet eben schon sehr,
sehr schnell. Um dein C-Tag auf diese Performance zu trimmen sind eben schon etwas mehr
als 100 LOC (lines of code) notwendig. Da muss man schon mit preforking oder gar jeden
Request als neuen Prozess forken arbeiten; ansonsten, wie du sagst, wird's wohl 10-100
mal langsamer als Apache ;)
Aber ich finds superinteressant, da man daran denke ich ne Menge lernen kann.  Hast Du eigentlich Erfahrungen wieviele % der Clients so Referer senden, denn sonst bringt mit die image-Geschicht eherzlich wenig ;-)

Wieder ein Thema-Wechsel? - Referer? - Senden IMHO (fast) alle Browser, mindestens 98%.
Nur, ob er einen Wert enthält, ist ne andere Frage: kein Wert heisst: URL direkt ein-
gegeben. Meinst du das?

Wobei, windows kann gar nicht forken, oder?

Jein, neue Prozesse starten geht auch mit Win (wer hätte das gedacht), aber es gibt
AFAIK nichts, was dem fork gleichkommt (Prozessgabelung und Deep-Cloning). Aber
cygwin machts möglich...

Wenn ich was in C++ schreibe, dann verwende ich die Cygwin Umgebung. Aber vermutlich ist das Programm dann nur unter Windows-PCs mit eben dieser Cygwin-Umgebung lauffähig, oder?

Die Umgebung braucht man nicht, nur die cygwin1.dll

Und vermutlich ist C dadurch auch erheblich langsamer, da es ja nicht wirklich OS-natives C ist.

Das, was ein Programm in diesem Kontext langsam macht, ist die Emulierung der UNIX-
Umgebung, das stimmt. Der Maschinencode bleibt ziemlich gleich.

Wenn ich ein Tool in C(++) schreiben will, welchen (freien) Compiler kann ich unter Win verwenden?

gcc gibt's AFAIK auch für Win. Mag mich erinnern, dass ich einige über google gefunden
hab, aber im Moment beschränke ich mich auf cygwin's gcc.

Ich wende meine bei try2hack frisch erforbenen "Cracker"-Kenntnisse an und such mir (frei)willige Unix-Server im Netz ;-)))

:-)))  Komm zu Papa, lieber Server! :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

hi!

Ich formuliere vorsichtiger: Ich nehme es zur Kenntnis :-)

Rasmus Lerdorf programmiert die Apache 1.3 Schnittstelle für PHP, daher mein Vertauen ;-)

Wieder ein Thema-Wechsel? - Referer? - Senden IMHO (fast) alle Browser, mindestens 98%.
Nur, ob er einen Wert enthält, ist ne andere Frage: kein Wert heisst: URL direkt ein-
gegeben. Meinst du das?

Naja, wenn ich jetzt Besuche Loggen will ohne auf originale Logfile und serverseites Live-Loggen zurückzugreifen, dann kann ich nur eine Grafik einbinden die auf einem anderen Rechner liegt um an die Daten zu komme, oder? Problem ist hier nur das der Client die Grafik cached, also muß man wohl header schicken die das möglicht unterbinden, keine Ahnung wie wirkungsvoll das ist. Jedenfalls ist der Referer das einzige was auf die tatsächlich angefragte Seite hinweist, und wenn der fehlt weiß ich nict wo sich der User befindet, also bringt mir das nichts(wenn es mir darum geht eben dieses zu loggen). Oder gibt es bessere Methoden eben dieses zu loggen? Vieleicht könnte man mit einem Javascript noch die aktuelle Zeit an die grafik-url hängen um wenigstens bei Javascript-enabled sicherzugehen das ein Request kommt.

Die Umgebung braucht man nicht, nur die cygwin1.dll

ach ja ;-)

Wenn ich ein Tool in C(++) schreiben will, welchen (freien) Compiler kann ich unter Win verwenden?

gcc gibt's AFAIK auch für Win. Mag mich erinnern, dass ich einige über google gefunden
hab, aber im Moment beschränke ich mich auf cygwin's gcc.

gcc, so habe ich gehört macht die Programme recht langsam, der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Ich wende meine bei try2hack frisch erforbenen "Cracker"-Kenntnisse an und such mir (frei)willige Unix-Server im Netz ;-)))

:-)))  Komm zu Papa, lieber Server! :-)

warum hast Du Dich nicht an try2hack.nl beteiligt? War ein großer Spaß ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Wieder ein Thema-Wechsel? - Referer? - Senden IMHO (fast) alle Browser, mindestens 98%.
Nur, ob er einen Wert enthält, ist ne andere Frage: kein Wert heisst: URL direkt ein-
gegeben. Meinst du das?
Naja, wenn ich jetzt Besuche Loggen will ohne auf originale Logfile und serverseites Live-Loggen zurückzugreifen, dann kann ich nur eine Grafik einbinden die auf einem anderen Rechner liegt um an die Daten zu komme, oder? Problem ist hier nur das der Client die Grafik cached, also muß man wohl header schicken die das möglicht unterbinden, keine Ahnung wie wirkungsvoll das ist. Jedenfalls ist der Referer das einzige was auf die tatsächlich angefragte Seite hinweist, und wenn der fehlt weiß ich nict wo sich der User befindet, also bringt mir das nichts(wenn es mir darum geht eben dieses zu loggen). Oder gibt es bessere Methoden eben dieses zu loggen? Vieleicht könnte man mit einem Javascript noch die aktuelle Zeit an die grafik-url hängen um wenigstens bei Javascript-enabled sicherzugehen das ein Request kommt.

Yo, die Graphik ist nicht die einzige Möglichkeit, wohl aber eine sehr einfache und
verbreitete. Das Caching kannst du sicherlich mit der HTTP-Response stark unterbinden,
aber wenn JS aktiviert ist, würde ich in jedem Fall noch eine Timestamp oder Random
Zahl anhängen.

Wenn ich ein Tool in C(++) schreiben will, welchen (freien) Compiler kann ich unter Win verwenden?

gcc gibt's AFAIK auch für Win. Mag mich erinnern, dass ich einige über google gefunden
hab, aber im Moment beschränke ich mich auf cygwin's gcc.
gcc, so habe ich gehört macht die Programme recht langsam, der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Ich nehme es zur Kenntnis :-)
Ich habe davon noch nichts gehört, und als ich mir den Code von GCC mal in Assembler
deassembliert ausgab (-S als Parameter, aus test.c wird test.s und enthält das Assembler
Äquivalent, ganz geniale Sache!), hatte ich einen guten Eindruck vom Code [meiner wohl
SEHR bescheidenen Meinung nach, hatte schon lange keine Assembler-Programme mehr
geschrieben ;)]. Aber es könnte gut sein, dass GCC in einigen Routingen langsamer ist,
als das der andere...

:-)))  Komm zu Papa, lieber Server! :-)

warum hast Du Dich nicht an try2hack.nl beteiligt? War ein großer Spaß ;-)

Na, ich kannte es nicht :-(
Aber was tun die da genau? - Hab die Website kurz angeschaut, aber Forum ist geschlossen
und beim Überfliegen habe ich auch vom Zweck wenig erfahren. Herausforderungen suchen
und lösen? - Klingt zumindest sehr verlockend... Muss mich da mal an einem freien
Wochenende "bewerben" :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo!

Yo, die Graphik ist nicht die einzige Möglichkeit, wohl aber eine sehr einfache und
verbreitete.

Was gibt es noch für möglichkeiten wenn ich keinen serverseitigen Code verwenden kann?

gcc, so habe ich gehört macht die Programme recht langsam, der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Ich nehme es zur Kenntnis :-)

Ich habe es auch nur in einem Forum gelesen, die sagten der Code wäre im Schnitt 30-40 % schneller. Naja, aber das Teil kostet dafür Geld(400 EUR!).

warum hast Du Dich nicht an try2hack.nl beteiligt? War ein großer Spaß ;-)

Na, ich kannte es nicht :-(

Nein? Das war ein netter Thread letzte Woche: </archiv/2003/2/38373/>(nicht zu viel lesen, da stehen einige Lösungen drin, udn dann machst keien Spaß mehr), aber Vorsicht, Suchtgefahr, kann ne Menge Zeit kosten, kommt auf Deine Fähigkeiten an ;-)

Aber was tun die da genau? - Hab die Website kurz angeschaut, aber Forum ist geschlossen
und beim Überfliegen habe ich auch vom Zweck wenig erfahren. Herausforderungen suchen
und lösen? - Klingt zumindest sehr verlockend... Muss mich da mal an einem freien
Wochenende "bewerben" :-)

Es geht darum verschiedene Passwort-Schutz? zu umgehen, in 10 Leveln, geht los mit einfachem Javascript, über Java, Dekompilieren, bis hin zum Ausnutzen von Exploits ;-) Macht Spaß, los gehts hier:
http://www.try2hack.nl/levels/level1.html

Grüße
Andreas

PS: Ich habe es bis Level 9 geschafft, aber das ist leider zur Zeit down :-(

[Philipp Hasenfratz]

Halihallo Andreas

Yo, die Graphik ist nicht die einzige Möglichkeit, wohl aber eine sehr einfache und
verbreitete.
Was gibt es noch für möglichkeiten wenn ich keinen serverseitigen Code verwenden kann?

Tja, eigentlich ist die Antwort nicht schwer: Alles was ein src oder evtl. ein href
Attribut hat. Evtl. mit Java-Applet, obwohl das schon wieder sehr stark vom Client
abhängt. Ich denke jedoch, dass das 1x1 Zählpixel-Image das einfachste ist.

gcc, so habe ich gehört macht die Programme recht langsam, der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Ich nehme es zur Kenntnis :-)
Ich habe es auch nur in einem Forum gelesen, die sagten der Code wäre im Schnitt 30-40 % schneller. Naja, aber das Teil kostet dafür Geld(400 EUR!).

OK, dann nehme ich 20ns verlangsamtes Abarbeiten gerne in Kauf ;)

warum hast Du Dich nicht an try2hack.nl beteiligt? War ein großer Spaß ;-)

Na, ich kannte es nicht :-(
Nein? Das war ein netter Thread letzte Woche: </archiv/2003/2/38373/>(nicht zu viel lesen, da stehen einige Lösungen drin, udn dann machst keien Spaß mehr), aber Vorsicht, Suchtgefahr, kann ne Menge Zeit kosten, kommt auf Deine Fähigkeiten an ;-)

Aha! Ich hatte sogar einige Postings dieses Threads gelesen, zumindest kamen mir einige
sehr, sehr bekannt vor, aber den Zusammenhang hab ich nicht mitbekommen; Gott sei Dank,
sonst wäre ich jetzt auch am cracken ;-)
Das Thema erinnert mich an eine Star Trek TNG Folge, als Riker auf Risa war und dort
von einer "Frau" ein kleines Spiel bekam. Tja, einige Tage später haben es alle auf dem
Schiff gespielt... Wesley und seine Freundin haben herausgefunden, dass es eine Droge
ist und das Lustzentrum anfällt (Alkohol des 24. Jh.); tja, die haben das Schiff dann
wieder unter Kontrolle gebracht (bzw. die Crew). Tja, so kommt mir das vor, die Droge
des Forums ;-)

Aber was tun die da genau? - Hab die Website kurz angeschaut, aber Forum ist geschlossen
und beim Überfliegen habe ich auch vom Zweck wenig erfahren. Herausforderungen suchen
und lösen? - Klingt zumindest sehr verlockend... Muss mich da mal an einem freien
Wochenende "bewerben" :-)

Es geht darum verschiedene Passwort-Schutz? zu umgehen, in 10 Leveln, geht los mit einfachem Javascript, über Java, Dekompilieren, bis hin zum Ausnutzen von Exploits ;-) Macht Spaß, los gehts hier:
http://www.try2hack.nl/levels/level1.html

Aloha... Scheint im Moment etwas down zu sein, aber...

PS: Ich habe es bis Level 9 geschafft, aber das ist leider zur Zeit down :-(

... ich werde kommen... Level 9 pahh, gibt's nur 10? - Mei, da hab ich noch wat vor du...
:-)

Auf jeden Fall Danke, du forderst mich wieder voll und ganz (Herausforderung
angenommen) :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Es geht darum verschiedene Passwort-Schutz? zu umgehen, in 10 Leveln, geht los mit einfachem Javascript, über Java, Dekompilieren, bis hin zum Ausnutzen von Exploits ;-) Macht Spaß, los gehts hier:
http://www.try2hack.nl/levels/level1.html

Aloha... Scheint im Moment etwas down zu sein, aber...

Hat wohl jemand den Sinn nicht verstanden und versucht das ganze per Brute-Force ;-)

PS: Ich habe es bis Level 9 geschafft, aber das ist leider zur Zeit down :-(

... ich werde kommen... Level 9 pahh, gibt's nur 10? - Mei, da hab ich noch wat vor du...

Tja, trotz bitten und betteln geben die mir nicht die url zu lvl 10, naja, aber es gibt ein Bonus-Level, aber das verstehe ich nicht, das ist glaube ich VB6 Code der sich nicht dekompilieren läßt, meines Wissens nur in Maschinencode den Du versteh mußt, naja, ich tues jedenfalls nicht ;-)

:-)

Auf jeden Fall Danke, du forderst mich wieder voll und ganz (Herausforderung
angenommen) :-)

Dann lass mal hören wies läuft(wenns wieder up ist), wenn Du dann bei Level 2 nicht mehr weiter kommst - Du weißt wie Du mich erreichst *SCNR*

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Es geht darum verschiedene Passwort-Schutz? zu umgehen, in 10 Leveln, geht los mit einfachem Javascript, über Java, Dekompilieren, bis hin zum Ausnutzen von Exploits ;-) Macht Spaß, los gehts hier:
http://www.try2hack.nl/levels/level1.html

Aloha... Scheint im Moment etwas down zu sein, aber...
Hat wohl jemand den Sinn nicht verstanden und versucht das ganze per Brute-Force ;-)

Tja, jetzt hatte ich grad root-Zugriff auf den Server und schon habe ich alles ganz
zum Schweigen gebracht ;-)  [oder hast du Zugriff auf die Site?]
Gute alte DoS - Attacke...

PS: Ich habe es bis Level 9 geschafft, aber das ist leider zur Zeit down :-(

... ich werde kommen... Level 9 pahh, gibt's nur 10? - Mei, da hab ich noch wat vor du...
Tja, trotz bitten und betteln geben die mir nicht die url zu lvl 10, naja, aber es gibt ein Bonus-Level, aber das verstehe ich nicht, das ist glaube ich VB6 Code der sich nicht dekompilieren läßt, meines Wissens nur in Maschinencode den Du versteh mußt, naja, ich tues jedenfalls nicht ;-)

VB6 Code deassemblieren und dann verstehen? - Mei o mei... wird mir übel ;)

Auf jeden Fall Danke, du forderst mich wieder voll und ganz (Herausforderung
angenommen) :-)
Dann lass mal hören wies läuft(wenns wieder up ist), wenn Du dann bei Level 2 nicht mehr weiter kommst - Du weißt wie Du mich erreichst *SCNR*

Level 2 is bei mir korrekt vom Laster gfallen... Aber ja, bei Level 3 weiss isch wo deine
Haus wohnt... *SCNR*

Viele Grüsse

Philipp

[Michael Schröpl]

Hi Andreas,

gcc gibt's AFAIK auch für Win. Mag mich erinnern, dass ich einige über google gefunden
hab, aber im Moment beschränke ich mich auf cygwin's gcc.
gcc, so habe ich gehört macht die Programme recht langsam,

mit welcher gcc-Optimierungsstufe übersetzt Du den Apache?
Das, was "configure" in seine Makefiles schreibt, ist nur ein Vorschlag - keine Religion ...

der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Sprichst Du von der Geschwindigkeit des Compilers oder von derjenigen des generierten Code?

Und vergleichst Du eine Code-Generator für genau eine Plattform (die der Hersteller zudem noch selbst geschaffen hat) mit einem Code-Generator, der auf vielen Plattformen mit wahrscheinlich geringen Abweichungen eingesetzt können werden muß?

Viele Grüße
      Michael

[Andreas Korthaus]

Hi!

mit welcher gcc-Optimierungsstufe übersetzt Du den Apache?
Das, was "configure" in seine Makefiles schreibt, ist nur ein Vorschlag - keine Religion ...

Hola! Ich bin gerade froh das ich mit ./configure; make; make install ein lauffähiges Programm hinbekomme ;-)
Nur mal ganz theoretisch _wenn_ ich das selbst kompilieren wollte, würde ich dann ./configure ausführen, und dann die generierten make-files verändern und danach make; make install, oder wie?

der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!

Sprichst Du von der Geschwindigkeit des Compilers oder von derjenigen des generierten Code?

Wenn ich das richtig verstanden habe vom generierten Code. Vor allem auf Intel-CPUs, auf AMD etwas weniger.

Und vergleichst Du eine Code-Generator für genau eine Plattform (die der Hersteller zudem noch selbst geschaffen hat) mit einem Code-Generator, der auf vielen Plattformen mit wahrscheinlich geringen Abweichungen eingesetzt können werden muß?

Ja, ich habe nunmal diese Plattform also warum soll ich  mir diese Kompatibilität "ans Bein binden"? Wenn ich damit meinen Code der nur hier und nirgends anders laufen soll 30-40% schneller bekomme, was ist dagegen einzuwenden? Das er theoretisch unter irgendeinem RISC-Prozesser nicht läuft? ISt doch egal, denn das will ich nicht, und wenn kann ich ihn auch neu kompilieren, dann von mir aus mit gcc oder g++!

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Nur mal ganz theoretisch _wenn_ ich das selbst kompilieren wollte, würde ich dann ./configure ausführen, und dann die generierten make-files verändern und danach make; make install, oder wie?

Das kannst Du irgendwie von außen so setzen, daß der "configure" es an den C-Compiler mit durchreicht ... Moment, ich schaue mal nach:

Compiler-Optionen

a) Optimierungsstufe 2 für den C-Compiler einstellen

#    (wird von 'configure' in alle Makefiles übertragen;
#     bei der gzip-Komprimierung entlastet das ggf. die CPU)

b) Dynamische Module auf 0 begrenzen

#    (aus Performance-Gründen wollen wir die nicht, und das spart RAM)
  export OPTIM='-O2 -DDYNAMIC_MODULE_LIMIT=0'

Und danach "configure" aufrufen ...

der Compiler von Intel soll dagegen sehr schnell sein, habe ich eben gelesen!
Und vergleichst Du eine Code-Generator für genau eine Plattform (die der Hersteller zudem noch selbst geschaffen hat) mit einem Code-Generator, der auf vielen Plattformen mit wahrscheinlich geringen Abweichungen eingesetzt können werden muß?
Ja, ich habe nunmal diese Plattform also warum soll ich  mir diese Kompatibilität "ans Bein binden"? Wenn ich damit meinen Code der nur hier und nirgends anders laufen soll 30-40% schneller bekomme, was ist dagegen einzuwenden? Das er theoretisch unter irgendeinem RISC-Prozesser nicht läuft? ISt doch egal, denn das will ich nicht, und wenn kann ich ihn auch neu kompilieren, dann von mir aus mit gcc oder g++!

Fairerweise mußt Du ihn mit einem Compiler vergleichen, der auf eine andere Plattform optimiert ist.

Viele Grüße
      Michael

[Michael Schröpl]

Hi Andreas,

Und der Apache soll verhältnismäßig langsam sein was das Ausliefern von statischen Seiten angeht habe ich mir sagen lassen! IIS z.B. sei schneller, und auch eienige abndere für Linux.

es gibt keine Möglichkeit, die Geschwindigkeit "des Apache" mit derjenigen "des IIS" zu vergleichen.

Das Unternehmen scheitert schon daran, daß es "den Apachen" gar nicht gibt.
Was es tatsächlich gibt, das ist ein aus einer konfigurierbaren (!) Menge von Modulen zusammengebundenes httpd-Binary, welches "einen bestimmten Apache" ausmacht.

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.

Wenn Du einen Apache auf diejenigen Funktionen reduzierst, die Du tatsächlich benötigst, und die entsprechenden Module gar nicht erst mit einkompilierst (oder die Funktion abschaltest, falls sie im core steckt - "AllowOverride None" ist so eine Direktive, und "Options FollowSymLinks" ebenfalls - lies mal den Apache Performance Tuning Guide), dann wird der Apache bei Zugriffen auf die immer noch identische statische Datei natürlich erheblich schneller.

Ist ja auch logisch, der Apache ist ein wirklich tooles und _flexibles_ programm, nur bin ich der Meinung das Flexibilität fast immer auf Kosten von Performance geht.

Deshalb verwende ich mod_so ja auch nicht, und mod_rewrite vermeide ich ebenfalls.

Ich brache keinen Webserver der den Request erstmal parst, analysiert,

Doch, den brauchst Du. Du mußt schließlich HTTP unterstützen.

mit irgendwelchen KOnfigurationsdaten abgleicht,

Das kommt darauf an, wie kompliziert diese Konfigurationsdaten sind - das liegt in Deiner direkten Einflußnahme.

loggt, und dann aus dem Dateisystem eine Datei holt,

Über mod_mmap_static kannst Du Deine Reponse im Hauptspeicher halten lassen und damit den Dateizugriff komplett vermeiden.

dynamisch einen Header erzeugt,

Du kennst mod_asis, das Dateien inklusive fertiger HTTP-Header unmanipuliert ausliefert?

Bei mir reichen 3 Schritte. HTTP-Header entgegennehmen, in Datei schreiben und fertigen Response senden, der immer gleich ist.

Das kann der Apache im Prinzip auch. Du mußt ihn nur so konfigurieren, daß er genau dies tut, und alles andere rauswerfen.

Ich denke wenn sich ein Apache-programmiere hinsetzt udn so eien Server in C schreibt wird er 10 bis 100 mal schnelle rals de Apache, das _muss_ er einfach!

Du kannst Dir auch einen Apache so "zurecht löschen", daß er genau Deine Anforderung erfüllt.
Oder Du kannst ein Apache-Modul schreiben, das Deine Anforderungen (Zählen und statische Antwort senden) erfüllt und ansonsten vom Apache-Server aufgerufen wird.

Wenn Du mit dem Apache konkurrieren können willst, dann liest erst mal die Beschreibung sämtlicher Module durch, die es bereits gibt ... ich erkenne da diverse Lücken bei Dir.

Viele Grüße
      Michael

[Andreas Korthaus]

Hi Michael!

es gibt keine Möglichkeit, die Geschwindigkeit "des Apache" mit derjenigen "des IIS" zu vergleichen.
Das Unternehmen scheitert schon daran, daß es "den Apachen" gar nicht gibt.
Was es tatsächlich gibt, das ist ein aus einer konfigurierbaren (!) Menge von Modulen zusammengebundenes httpd-Binary, welches "einen bestimmten Apache" ausmacht.

Naja, aber ich kannmir auf derselben Maschine einen für meine Zwecke optimalen IIS und einen optimalen Apachen zusammenbauen, und dieselben Daten im Doc-Root und die selben Requests abfeuern udn messen, dann shee ich welcher schneller ist, das das nicht allgemeingültig sein kann ist klar, zeigt aber eine Tendenz auf, oder?

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.

Wenn Du einen Apache auf diejenigen Funktionen reduzierst, die Du tatsächlich benötigst, und die entsprechenden Module gar nicht erst mit einkompilierst (oder die Funktion abschaltest, falls sie im core steckt - "AllowOverride None" ist so eine Direktive, und "Options FollowSymLinks" ebenfalls - lies mal den Apache Performance Tuning Guide), dann wird der Apache bei Zugriffen auf die immer noch identische statische Datei natürlich erheblich schneller.

Das habe ich auch eingesehen, der Apache wird schneller als ich es je brauchen würde!

Ist ja auch logisch, der Apache ist ein wirklich tooles und _flexibles_ programm, nur bin ich der Meinung das Flexibilität fast immer auf Kosten von Performance geht.

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!

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?

mit irgendwelchen KOnfigurationsdaten abgleicht,

Das kommt darauf an, wie kompliziert diese Konfigurationsdaten sind - das liegt in Deiner direkten Einflußnahme.

stimmt, aber ich werde sie nicht los, einiges muss einfach so gelesen werden.

loggt, und dann aus dem Dateisystem eine Datei holt,

Über mod_mmap_static kannst Du Deine Reponse im Hauptspeicher halten lassen und damit den Dateizugriff komplett vermeiden.

Sowas kann der Apache??? Interessant...

dynamisch einen Header erzeugt,

Du kennst mod_asis, das Dateien inklusive fertiger HTTP-Header unmanipuliert ausliefert?

und das auch...

Bei mir reichen 3 Schritte. HTTP-Header entgegennehmen, in Datei schreiben und fertigen Response senden, der immer gleich ist.

Das kann der Apache im Prinzip auch. Du mußt ihn nur so konfigurieren, daß er genau dies tut, und alles andere rauswerfen.

ja, Du hast sicher Recht.

Wenn Du mit dem Apache konkurrieren können willst, dann liest erst mal die Beschreibung sämtlicher Module durch, die es bereits gibt ... ich erkenne da diverse Lücken bei Dir.

Das stimmt, hätte nie gedacht das es sowas gibt, vielen Dank für die Hinweise!

Grüße
Andreas

[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