Philipp Hasenfratz: OT: performanter Server für HTTP-Logging

Beitrag lesen

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

0 40

Eigener Webserver in Delphi

Kay
  • sonstiges
  1. 0
    Philipp Hasenfratz
  2. 0
    Philipp Hasenfratz
    1. 0
      Kay
    2. 0
      Andreas Korthaus
      1. 0
        Philipp Hasenfratz
        1. 0

          OT: performanter Server für HTTP-Logging

          Andreas Korthaus
          • webserver
          1. 0
            Philipp Hasenfratz
            1. 0
              Andreas Korthaus
              1. 0
                Philipp Hasenfratz
              2. 0
                Michael Schröpl
            2. 0
              Sven Rautenberg
              1. 0
                Philipp Hasenfratz
                1. 0
                  Andreas Korthaus
                  1. 0
                    Philipp Hasenfratz
                    1. 0
                      Andreas Korthaus
                      1. 0
                        Andreas Korthaus
                        1. 0
                          Philipp Hasenfratz
                          1. 0
                            Andreas Korthaus
                            1. 0
                              Philipp Hasenfratz
                              1. 0
                                Andreas Korthaus
                                1. 0
                                  Philipp Hasenfratz
                              2. 0
                                Michael Schröpl
                                1. 0
                                  Andreas Korthaus
                            2. 0
                              Michael Schröpl
                        2. 0
                          Michael Schröpl
                          1. 0
                            Andreas Korthaus
                      2. 0
                        Philipp Hasenfratz
                        1. 0
                          Andreas Korthaus
                          1. 0
                            Philipp Hasenfratz
                            1. 0
                              Andreas Korthaus
                              1. 0
                                Philipp Hasenfratz
                                1. 0
                                  Andreas Korthaus
                                  1. 0
                                    Philipp Hasenfratz
                          2. 0
                            Michael Schröpl
                            1. 0
                              Andreas Korthaus
                              1. 0
                                Michael Schröpl
                  2. 0
                    Michael Schröpl
                    1. 0
                      Andreas Korthaus
                      1. 0
                        Michael Schröpl