Geschwindigkeit...

[Philipp Hasenfratz]

Halihallo Forumer

Meine Frage ist, wie mir selbst bewusst ist, nicht beantwortbar; aber ich würde gerne eure Meinungen und Erfahrungen einholen:

Ich muss eine Serverseitige Anwendung programmieren, um die Anzahl der Benutzer zu analysieren (bzw. zu speichern). Es handelt sich hierbei eigentlich nur um ein "Statistik-Programm". Das "Problem" ist die Geschwindigkeit: Wir kriegen Requests von verschiedenen anderen Sites und somit summieren sich die Requests auf unseren Server... => Überlastungsgefahr...

Zur Performance:
Ich hab das Script bei mir lokal auf dessen Geschwindigkeit geprüft. Vom ersten Befehl bis zum letzten braucht das Script ca. 50 Millisekunden (der Server dürfte ca. 1.5 mal schneller sein; wage Schätzung; das hängt ja auch von tausenden von Faktoren ab). Natürlich kommt dann noch einiges für den Start und Initialisierung des Perl-Interpreters hinzu und das Spoolen vom WebServer. Online läuft das ganze über einen AMD mit 750MHz, SCSI, (ich weiss, dass diese Angaben nicht sehr relevant sind) und was noch wichtiger ist: Apache mit mod_perl. Das ganze Programm ist "leider" in Perl, da C-Anwendungen nicht unterstützt werden (welche ja um ein vielfaches schneller wären). Zur Zeit läuft dies auf einer Maschine mit vielen Webs (normaler Webspace).

Jetzt stellt sich bei mir die Frage: Wieviele Requests kann der Server ertragen? - Gehen wir mal von der optimalen Konstellation aus, dass wir der einzige Webspace auf'm Rechner sind; alles unter mod_perl läuft und die Requests gleich verteilt sind. Wieviel hält ein Server aus? - Klar, keiner kann mir eine genaue Zahl nennen; mich interessieren auch nur die 10-Potenzen... Sind es 1 Request/s, 10, 100, 1000 oder gar 10000??? - Hat jemand Erfahrungen in dieser Angelegenheit?

Viele Grüsse

Philipp

[Mulder]

das ganze über einen AMD mit 750MHz, SCSI, (ich weiss, dass diese

Jetzt stellt sich bei mir die Frage: Wieviele Requests kann der Server ertragen? - Gehen wir mal von der optimalen Konstellation aus, dass wir der einzige Webspace auf'm Rechner sind; alles unter mod_perl läuft und die Requests gleich verteilt sind. Wieviel hält ein Server aus? - Klar, keiner kann mir eine genaue Zahl nennen; mich interessieren auch nur die 10-Potenzen... Sind es 1 Request/s, 10, 100, 1000 oder gar 10000??? - Hat jemand Erfahrungen in dieser Angelegenheit?

Kommt auch auf die Anbindung ans Netz an. Über 100 sollten es schon sein (das reicht auch für jede normale Website, denn das sind dann 8.64 Millionen in 24 Stunden).

Mal was aus der Praxis:
www.fuehrerschein.de, Dual PII-400, 256 MB, NT 4.0, 40 GB Traffic/Monat, mehrere 100.000 Requests/Monat (inzwischen hat der allerdings nen neuen Server :-).

10 K requests/s schaffen AFAIK nur 2 oder 3 Webserver auf der Welt. Ab einer gewissen Größenordnung benutzt man eh Load Balancing.

[Philipp Hasenfratz]

Halihallo Mulder

das ganze über einen AMD mit 750MHz, SCSI, (ich weiss, dass diese

Jetzt stellt sich bei mir die Frage: Wieviele Requests kann der Server ertragen? - Gehen wir mal von der optimalen Konstellation aus, dass wir der einzige Webspace auf'm Rechner sind; alles unter mod_perl läuft und die Requests gleich verteilt sind. Wieviel hält ein Server aus? - Klar, keiner kann mir eine genaue Zahl nennen; mich interessieren auch nur die 10-Potenzen... Sind es 1 Request/s, 10, 100, 1000 oder gar 10000??? - Hat jemand Erfahrungen in dieser Angelegenheit?

Kommt auch auf die Anbindung ans Netz an. Über 100 sollten es schon sein (das reicht auch für jede normale Website, denn das sind dann 8.64 Millionen in 24 Stunden).

Anbindung ist 10MBit; Datentransfer ist sehr klein, da dieser nur aus einem HTTP-Request und einem simplen, ca. 100 Byte grossem Response besteht. 100? - Hm. das klingt schon mal sehr gut, fast zu gut als dass ich es glaube... Meinst du wirklich, dass ein Durchschnitts-Server wie der von mir genannte gesamthaft 100 Requests auf Perl-Scripts aushält? - Scheint mir eigentlich sehr viel zu sein. Das würde ja bedeuten, dass jedes Script nicht mehr als 10ms brauchen dürfte, ohne sich mit anderen zu überlagern... Und langzeitig gesehen, würden Überlagerungen zum Absturz führen (kurzzeitig ist es kein Problem in Multitasking, aber längerfristig würden sich immer mehr Scripts überlagern und die Prozessorzeit vernichten)...

Mal was aus der Praxis:
www.fuehrerschein.de, Dual PII-400, 256 MB, NT 4.0, 40 GB Traffic/Monat, mehrere 100.000 Requests/Monat (inzwischen hat der allerdings nen neuen Server :-).

naja, das sind ja eigentlich "sehr wenige"/Sekunde... Aber natürlich muss man beachten, dass es Stosszeiten gibt und sich die Requests fast immer innerhalb der Geschäftszeiten liegen und noch einige am Abend... Somit kann man davon ausgehen, dass die wirklichen Stosszeiten doppelt - dreifach soviele Requests/Sekunde haben, als der Durchschnitt...

10 K requests/s schaffen AFAIK nur 2 oder 3 Webserver auf der Welt. Ab einer gewissen Größenordnung benutzt man eh Load Balancing.

LoadBalancing ist unweigerlich von nöten... Wird auch kommen... Bisher habe ich eine proprietäre Lösung erarbeitet, dass wir für jede Site einen eigenen Server mit individuellem Tag haben könnten, falls die Site derart grosse Impressions hat... Die Daten werden dann ich niederen Auslastungszeiten an den Hauptserver transferiert.

Viele Grüsse und Danke für die Einschätzung

Philipp

[Andreas]

Hallo!
Zur Not könntst Du ja den "Härtefall" mal nachstellen indem Du von einem(oder einigen) anderen Servern über ein Scripts sehr viele Requests sendest! Das kannst Du ja alles messen und wie Euer Server darauf reagiert.
Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Zur Not könntst Du ja den "Härtefall" mal nachstellen indem Du von einem(oder einigen) anderen Servern über ein Scripts sehr viele Requests sendest! Das kannst Du ja alles messen und wie Euer Server darauf reagiert.

Yo, daran hab ich auch schon gedacht. Das Problem ist, dass ich ziemlich viele Server haben müsste, da ich sonst nie auf eine stattliche Anzahl Requests komme (bzw. die Auswertung verfälscht werden würde). Es müssten ja versuchsweise über 100 Requests/Sekunde eintreffen. Ich bräuchte ca. 10 Server, vondenen jeder 10 Requests in einer Sekunde sendet; dies lässt sich durch forken dieses programmcodes erreichen:

use LWP::Simple;
&LWP::Simple::get( 'http://www.domain.de/cgi-bin/stirb-schnell.pl' );

... Nur habe ich keine 10 Server. Das Problem ist, wenn ich weniger nehme, dann wird das Ergebnis stark vom Sender-Server selbst gefälscht, da dieser auch überlastet ist und gar nicht soviele Requests ausführen kann, dass der andere Server abrauscht...

Aber du hast recht. Das sollte ich wirklich mal versuchen... Etwa drei-vier Server kann ich ja auftreiben... Ich werde heute Abend, morgen oder übermorgen was derartiges basteln...

Viele Grüsse

Philipp

[Andreas]

Hi!

Aber du hast recht. Das sollte ich wirklich mal versuchen... Etwa drei-vier Server kann ich ja auftreiben... Ich werde heute Abend, morgen oder übermorgen was derartiges basteln...

Nur mal zum Spaß:

<?
$anzahl = 100;

$host = "www.php.net";
$request = "/links.php";

$strHeader = "HEAD $request HTTP/1.0\r\n";
$strHeader .= "Host: $host\r\n";
$strHeader .= "Connection: close\r\n";
$strHeader .= "\r\n";

// Open the connection

$start = time();

for ($i=1; $i < $anzahl; $i++){

$fp = fsockopen($host, 80);
    fputs($fp, $strHeader);
    fclose ($fp);
}

$ende = time();
$sekunden = $ende - $start;

echo "In $sekunden Sekunden wurden $i Requests an $host$request abgesendet\n";

?>

So schaffe ich mit PHP nichtmal 10 Requests pro Sekunde. Aber kann ich nicht einfach fsockopen aus dere Schleife Auslagern und die Socket auslagern? Dann werden über 1000 schleifendurchläufe pro Millisekunde geschafft ;-) Aber das scheint mir utopisch.

Kann man das den noch irgendwie beschleunigen, oder ist PERl da deutlich schneller? Warum, dauer das absenden so lange?

Grüße
Andreas

[Christian Kruse]

Hallo,

So schaffe ich mit PHP nichtmal 10 Requests pro Sekunde.

Kein Wunder :)

Aber kann ich nicht einfach fsockopen aus dere Schleife Auslagern
und die Socket auslagern?

Nicht so richtig. Aber du kannst was anderes machen (Perl, weil man
in PHP nicht forken kann):

use LWP::Simple;

sub waiter {
 wait;
 $SIG{CHLD} = &waiter; # for SysV
}

sub make_conn() {
  get('http://wwwtech.de/');
}

$SIG{CHLD} = &waiter;
for(1..1000) {
  my $pid = fork();
  if(defined $pid) {
    if(!$pid) {
      make_conn();
      exit(0);
    }
  }
  else {
    die("Could not fork!");
  }
}

Kann man das den noch irgendwie beschleunigen,

Ja: mehrere Verbindungen gleichzeitig, nicht nacheinander machen :)

oder ist PERl da deutlich schneller?

Das hat nix mit Perl oder PHP zu tun -- das liegt am Protokoll.

Warum, dauer das absenden so lange?

Nicht das Absenden dauert lange, sondern das Aufbauen der Verbindung
dauert lange. Bei TCP/IP muessen 3 Pakete geschickt werden, um eine
Conn aufzubauen (der 3-Wege-Handshake):

You                           Host
                  --> SYN  --> Listens
Waiting for ACK   <-- ACK  <-- Waits for ACK
Established       --> ACK  --> Established

Dasselbe gilt fuer den Abbau einer Verbindung:

You                       Host
              --> FIN --> Established
Waits for ACK <-- ACK <-- Waits for ACK
Closed        --> ACK --> Closed

Was zum Lesen dazu:

http://sparky.freesoft.org/CIE/Course/Section4/10.htm

Dazu kommt, dass die Pakete eventuell ueber n Rechner gehen muessen.
Du kannst das Netzwerk-Segment, in dem der Rechner steht,
im Normalfall nicht direkt erreichen, sondern musst ueber sog.
'Router' gehen. Herausfinden, wieviele Router du besuchst, kannst
du mit 'traceroute'.

Gruesse,
 CK

[Andreas]

Hi!

So schaffe ich mit PHP nichtmal 10 Requests pro Sekunde.

Aber kann ich nicht einfach fsockopen aus dere Schleife Auslagern
und die Socket auslagern?

Nicht so richtig. Aber du kannst was anderes machen (Perl, weil man
in PHP nicht forken kann):

Also in PHP müßte ich jedesmal mit fsockopen eine Verbindung aufbauan, und die auch wieder schließen, richtig?

use LWP::Simple;

sub waiter {
wait;
$SIG{CHLD} = &waiter; # for SysV
}

sub make_conn() {
  get('http://wwwtech.de/');
}

$SIG{CHLD} = &waiter;
for(1..1000) {
  my $pid = fork();
  if(defined $pid) {
    if(!$pid) {
      make_conn();
      exit(0);
    }
  }
  else {
    die("Could not fork!");
  }
}

d.h. Du baust 1000 Parallele Verbindungen auf?

Kann man das den noch irgendwie beschleunigen,

Ja: mehrere Verbindungen gleichzeitig, nicht nacheinander machen :)

In PHP geht das nicht, oder? höchtens durch 10 Scripte ich die parallel starte, oder?

oder ist PERl da deutlich schneller?

Das hat nix mit Perl oder PHP zu tun -- das liegt am Protokoll.

ja, aber wenn PHP nicht parallel in einem Script mehrere Verbindungen öffnen kann hat hat es ja sehr wohl was mit PHP/PERl zu tun, oder?

Warum, dauer das absenden so lange?

Nicht das Absenden dauert lange, sondern das Aufbauen der Verbindung
dauert lange. Bei TCP/IP muessen 3 Pakete geschickt werden, um eine
Conn aufzubauen (der 3-Wege-Handshake):

You                           Host
                  --> SYN  --> Listens
Waiting for ACK   <-- ACK  <-- Waits for ACK
Established       --> ACK  --> Established

Dasselbe gilt fuer den Abbau einer Verbindung:

You                       Host
              --> FIN --> Established
Waits for ACK <-- ACK <-- Waits for ACK
Closed        --> ACK --> Closed

Was zum Lesen dazu:

Also die ganze Komunikation findet dann jedesmal in 1/10 Sekunde statt? Über die Entfernung? Ich dachte man schickt nur einfach den Request ab und kümmert sich nicht um den Rest, im prinzip ist es für einen derartiegen Test ja nicht wichtig ob die bestätigung kommt, das sihet man ja dann auf dem Server, daher meien Idee fsockopen auszulagern

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

So schaffe ich mit PHP nichtmal 10 Requests pro Sekunde.

Aber kann ich nicht einfach fsockopen aus dere Schleife Auslagern
und die Socket auslagern?

Nicht so richtig. Aber du kannst was anderes machen (Perl, weil man
in PHP nicht forken kann):

Also in PHP müßte ich jedesmal mit fsockopen eine Verbindung aufbauan, und die auch wieder schließen, richtig?

Das wäre immer noch sequentiell; mit perl kann man 1000 Prozesse öffnen, die dann getrennt voneinander zur _selben_ Zeit das Socket öffnen.

oder ist PERl da deutlich schneller?

Das hat nix mit Perl oder PHP zu tun -- das liegt am Protokoll.
ja, aber wenn PHP nicht parallel in einem Script mehrere Verbindungen öffnen kann hat hat es ja sehr wohl was mit PHP/PERl zu tun, oder?

Jain ;-)
Perl ist genau gleich schnell/langsam wie php, nur kann man mit perl einen Prozess forken (also einen detached process starten); dann laufen eben zwei Programme zur selben Zeit...

[...]

Also die ganze Komunikation findet dann jedesmal in 1/10 Sekunde statt? Über die Entfernung? Ich dachte man schickt nur einfach den Request ab und kümmert sich nicht um den Rest, im prinzip ist es für einen derartiegen Test ja nicht wichtig ob die bestätigung kommt, das sihet man ja dann auf dem Server, daher meien Idee fsockopen auszulagern

Öm... Das passiert auch alles automatisch. Darüber musst du dir nicht den Kopf zerbrechen; beeinflussen kannst du es auch nicht.

Viele Grüsse

Philipp

[Andreas]

Hallo!

Das wäre immer noch sequentiell; mit perl kann man 1000 Prozesse öffnen, die dann getrennt voneinander zur _selben_ Zeit das Socket öffnen.

Aber damit sollte doch das problem gelöst sein und Du verwendest einfach einen Server, bräuchtest dann ja nur 10-20 Prozesse um 100 Requests die Sekkunde zu simulieren, oder?

Wo ist denn jetzt der Engpass? CPU/RAM? Wäre ja mal interessant zu testen wieviele Request die Hardware schafft ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Das wäre immer noch sequentiell; mit perl kann man 1000 Prozesse öffnen, die dann getrennt voneinander zur _selben_ Zeit das Socket öffnen.

Aber damit sollte doch das problem gelöst sein und Du verwendest einfach einen Server, bräuchtest dann ja nur 10-20 Prozesse um 100 Requests die Sekkunde zu simulieren, oder?

Ne, so einfach ist es leider nicht. Klar kann ich 100 Prozesse starten, aber diese Prozesse um einen Request auf den zu testenden Server auszuführen müssen auch eine Verbindung aufbauen und waren bis sie wieder geschlossen wird => Der Request-Server ist dann genauso ausgelastet (oder gar noch mehr), wie der Response-Server; somit wird das Ergebnis völlig verfälscht. Deshalb bräuchte ich auch ca. 10 Server, dass das Ergebnis überhaupt valide ist...

Wo ist denn jetzt der Engpass? CPU/RAM? Wäre ja mal interessant zu testen wieviele Request die Hardware schafft ;-)

Och, die schafft einige ;)
Schliesslich läuft das ganze unter mod_perl... Da wird dann nicht jedesmal der ganze Interpreter mitgeladen; und der braucht wohl am meisten Platz (zumindest bei meinem kleinen Script)...

Viele Grüsse

Philipp

[Christian Kruse]

Hallo,

Also in PHP müßte ich jedesmal mit fsockopen eine Verbindung
aufbauan, und die auch wieder schließen, richtig?

Ja.

d.h. Du baust 1000 Parallele Verbindungen auf?

Nahezu parallel, ja. Wirklich parallel ist nicht moeglich.

In PHP geht das nicht, oder? höchtens durch 10 Scripte ich die
parallel starte, oder?

Ja.

ja, aber wenn PHP nicht parallel in einem Script mehrere
Verbindungen öffnen kann hat hat es ja sehr wohl was mit PHP/PERl
zu tun, oder?

Nein. Wie gesagt. Es liegt am Protokoll.

Also die ganze Komunikation findet dann jedesmal in 1/10 Sekunde
statt?

Ja.

Über die Entfernung?

Ja.

Ich dachte man schickt nur einfach den Request ab und kümmert sich
nicht um den Rest,

Stimmt auch, das uebernimmt eine Schicht unterhalb des Scriptes fuer
dich :)

im prinzip ist es für einen derartiegen Test ja nicht wichtig ob
die bestätigung kommt,

Doch, ist es. Die TCP-Verbindung muss bestehen. Sonst schickst du
hinterher zig Requests ins Nirvana und merkst nix davon.

das sihet man ja dann auf dem Server,

Du hast mich nicht verstanden. HTTP ist ein Protokoll, dass auf
TCP-Basis laeuft (waehrend TCP wieder ueber IP laeuft :). Und bevor
ein HTTP-Request abgeschickt werden kann, muss eine TCP-Verbindung
aufgebaut werden. TCP ist naemlich, im Gegensatz zu HTTP, kein
Stati-loses Protokoll, sondern ein Streaming-Protokoll, das genau
definierte Stati hat.

Gruesse,
 CK

[Andreas]

Hi!

das sihet man ja dann auf dem Server,

Du hast mich nicht verstanden. HTTP ist ein Protokoll, dass auf
TCP-Basis laeuft (waehrend TCP wieder ueber IP laeuft :). Und bevor
ein HTTP-Request abgeschickt werden kann, muss eine TCP-Verbindung
aufgebaut werden. TCP ist naemlich, im Gegensatz zu HTTP, kein
Stati-loses Protokoll, sondern ein Streaming-Protokoll, das genau
definierte Stati hat.

Doch das kannte ich wohl(so grob ;-)), was ich meinte, wenn ich einfach requests abschicken würde/könnte ohne jegliche Bestätigung abzuwarten(was vermutlich _sehr_ viel schneller wäre) könnte ich doch in dem Script das die HTTP-Requests entgennimmt einfach loggen(oder über die Server Logs) und am Ende gucken ob alles angekommen ist, halt der Geschwindigkeit zuliebe, sicher hat das sonst keinen Sinn!

Mich wundert nur das dieser Handshake in so kurzer Zeit um die ganze Welt funktionieren kann, irgendwie beeindruckend!

Grüße
Andreas

[Christian Kruse]

Hallo,

Doch das kannte ich wohl(so grob ;-)), was ich meinte, wenn ich
einfach requests abschicken würde/könnte ohne jegliche Bestätigung
abzuwarten

Das kannst du nicht. Die SYN-FIN-ACK Sequenzen *muessen* geschehen.

(was vermutlich _sehr_ viel schneller wäre) könnte ich doch in dem
Script das die HTTP-Requests entgennimmt einfach loggen(oder über
die Server Logs) und am Ende gucken ob alles angekommen ist, halt
der Geschwindigkeit zuliebe, sicher hat das sonst keinen Sinn!

Oh, dass du die SYN-FIN-ACK-Sequenzen abwarten musst, heisst ja nicht,
dass du auch die Daten empfangen musst. Du kannst ja auch mitten im
Stream ein 'Ich will nicht mehr!' schicken und die Conn abbauen.

Mich wundert nur das dieser Handshake in so kurzer Zeit um die
ganze Welt funktionieren kann, irgendwie beeindruckend!

Ja :)

Gruesse,
 CK

[Christian Kruse]

Hoi,

Dasselbe gilt fuer den Abbau einer Verbindung:

You                       Host
              --> FIN --> Established
Waits for ACK <-- ACK <-- Waits for ACK
Closed        --> ACK --> Closed

Hier habe ich Quark erzaehlt. Es wird gesendet:

Established   --> FIN --> Established
Waits for ACK <-- ACK <-- Waits for ACK
Waits for FIN <-- FIN <-- Waits for ACK
Closed        --> ACK --> Closed

Und zwar deshalb, um Manipulationen durch Verbindungs-fremde Pakete
vorzubeugen.

Gruesse,
 CK

[Christian Kruse]

Hallo Philipp,

Und langzeitig gesehen, würden Überlagerungen zum Absturz führen
(kurzzeitig ist es kein Problem in Multitasking, aber
längerfristig würden sich immer mehr Scripts überlagern und die
Prozessorzeit vernichten)...

Das ist natuerlich quatsch. Abstuerzen tut da auf einem vernuenftigen
Betriebssystem gar nix. Neue Requests werden halt einfach in eine
Warteschleife gepackt und erst bearbeitet, wenn wieder Ressourcen
verfuegbar sind. Genau das bedeutet ueberigens der Server-Load: Der
Load sind die Anzahl von Prozessen, die in der Warteschleife vor
der CPU stehen.

Wenn Computer bei mittel- bis laengerfristiger Ueberlastung
abstuerzen wuerden, waere der alte Server nie gelaufen :) Und man
haette damals nie im Leben Win3.1 einsetzen koennen: auf meinem
ersten PC war das eine echte Qual... der war *wirklich* ueberlastet,
und zwar dauerhaft :)

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Und langzeitig gesehen, würden Überlagerungen zum Absturz führen
(kurzzeitig ist es kein Problem in Multitasking, aber
längerfristig würden sich immer mehr Scripts überlagern und die
Prozessorzeit vernichten)...

Das ist natuerlich quatsch. Abstuerzen tut da auf einem vernuenftigen
Betriebssystem gar nix.

Und da das Betriebssystem Linux heisst, muss ich dir natürlich recht geben ;-)

Neue Requests werden halt einfach in eine
Warteschleife gepackt und erst bearbeitet, wenn wieder Ressourcen
verfuegbar sind. Genau das bedeutet ueberigens der Server-Load: Der
Load sind die Anzahl von Prozessen, die in der Warteschleife vor
der CPU stehen.

Wirklich? - Werden bei mod_perl die Prozesse (Threads) automatisch in die Queue eingefügt, wenn die Auslastung 100% ist? - Oder macht dies Linux von sich aus?
Ich habe noch nie gehört, dass es eine derartige Warteschleife geben soll; dachte einfach, dass dann jedes Programm einfach eine sehr viel kleinere Timesplice bekommt.

Wenn Computer bei mittel- bis laengerfristiger Ueberlastung
abstuerzen wuerden, waere der alte Server nie gelaufen :) Und man
haette damals nie im Leben Win3.1 einsetzen koennen: auf meinem
ersten PC war das eine echte Qual... der war *wirklich* ueberlastet,
und zwar dauerhaft :)

Mei, bin ich froh, dass mein MSX mit 3.14 MHz noch kein Multitasking OS hatte ;-)
Aber der 486sx, 25MHz hatte bei Win3.1 bei einigen Progis auch so seine Probleme...

Viele Grüsse

Philipp

[Mulder]

Neue Requests werden halt einfach in eine
Warteschleife gepackt und erst bearbeitet, wenn wieder Ressourcen
verfuegbar sind. Genau das bedeutet ueberigens der Server-Load: Der
Load sind die Anzahl von Prozessen, die in der Warteschleife vor
der CPU stehen.

Ich habe noch nie gehört, dass es eine derartige Warteschleife geben soll; dachte einfach, dass dann jedes Programm einfach eine sehr viel kleinere Timesplice bekommt.

Das ist doch ein Grundprinzip von Message Passing Systems (also alles, was eine Connection aufmacht, Webserver, Datenbank, ...).
Ist der Respondent überlastet, kommen neue Requests in die Warteschlange (Queue). Deswegen ist es bei Überlastung des Servers ja auch normalerweise immer so, daß der Rechner nicht abschmiert und nur die Clients längere Wartezeiten haben (oder eben "Connection refused" bekommen).
Andernfalls wäre das Prinzip ja auch untauglich. :-)

[Christian Kruse]

Hallo Philipp,

Wirklich? - Werden bei mod_perl die Prozesse (Threads) automatisch
in die Queue eingefügt, wenn die Auslastung 100% ist?

Natuerlich. Aber das ist nichts, was mod_perl macht, sondern das OS.

• Oder macht dies Linux von sich aus?

Ja.

Ich habe noch nie gehört, dass es eine derartige Warteschleife
geben soll; dachte einfach, dass dann jedes Programm einfach eine
sehr viel kleinere Timesplice bekommt.

Noe. Wenn ein UNIX-aehnliches System (SystemV, BSD) so ausgelastet
ist, dass es nicht mehr genuegend Ressourcen mehr frei hat, werden
solange Prozesse in eine Warteschleife geschickt, bis wieder genug
Ressourcen frei geworden sind.

Aber der 486sx, 25MHz hatte bei Win3.1 bei einigen Progis auch so
seine Probleme...

Naja, das OS war ja auch nicht MultiTasking-faehig. DOS, naemlich :)
Aber Win3.1 hat versucht (die Betonung liegt auf 'versucht'),
MultiTasking zu emulieren. Das ging irgendwie aber alles nicht so
richtig, teils, weil die PCs noch zu langsam waren, teils, weil nicht
geschickt genug skaliert wurde. IMHO hat gutes MultiTasking eh erst
mit pipegelinten (geiles Wort! *g*) CPUs angefangen :)

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Ich habe noch nie gehört, dass es eine derartige Warteschleife
geben soll; dachte einfach, dass dann jedes Programm einfach eine
sehr viel kleinere Timesplice bekommt.

Noe. Wenn ein UNIX-aehnliches System (SystemV, BSD) so ausgelastet
ist, dass es nicht mehr genuegend Ressourcen mehr frei hat, werden
solange Prozesse in eine Warteschleife geschickt, bis wieder genug
Ressourcen frei geworden sind.

Klingt einleuchtend ;)

Aber der 486sx, 25MHz hatte bei Win3.1 bei einigen Progis auch so
seine Probleme...

Naja, das OS war ja auch nicht MultiTasking-faehig. DOS, naemlich :)
Aber Win3.1 hat versucht (die Betonung liegt auf 'versucht'),
MultiTasking zu emulieren. Das ging irgendwie aber alles nicht so
richtig, teils, weil die PCs noch zu langsam waren, teils, weil nicht
geschickt genug skaliert wurde. IMHO hat gutes MultiTasking eh erst
mit pipegelinten (geiles Wort! *g*) CPUs angefangen :)

halt eben nicht preemptiv... Nur kooperativ. Z. B. kann Win3.1 während eines Interrupts (besonders wenn auf Disketten zugegriffen wurde, war dies höllisch lästig) nicht in ein anderes Programm wechseln. Zudem mussten sich alle Win-Anwendungen eine Timesplice teilen... Pfui, pfui, pfui... ;-)

Viele Grüsse

Philipp

PS: Was meinst du zu der Aussage von Mulder? - 100 Requests/s auf ein Script möglich oder nicht?

[Christian Kruse]

Hallo Philipp,

Klingt einleuchtend ;)

Ich sollte die Aussage aber etwas einschraenken und sagen 'bei allem
*mir bekannten* UNIX-aehnlichen Systemen' :) Wie das bei Windows
ist, btw, weiss ich nicht.

halt eben nicht preemptiv... Nur kooperativ.

Richtig :)

Z. B. kann Win3.1 während eines Interrupts (besonders wenn auf
Disketten zugegriffen wurde, war dies höllisch lästig) nicht in ein
anderes Programm wechseln.

Oh ja, davon kann ich auch noch lieder singen *g*

PS: Was meinst du zu der Aussage von Mulder?

Vollkommen korrekt. Auf aelteren Systemen war die Listen-Queue
ueberigens auf 5 Requests beschraenkt :)

• 100 Requests/s auf ein Script möglich oder nicht?

Oh, das duerfte ziemlich stark vom System, der Anbindung und der
Plattform abhaengen. Aber Prinzipiell -- warum nicht?

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Christian

Klingt einleuchtend ;)

Ich sollte die Aussage aber etwas einschraenken und sagen 'bei allem
*mir bekannten* UNIX-aehnlichen Systemen' :) Wie das bei Windows
ist, btw, weiss ich nicht.

dort kommt ein bluescreen mit dem Fehlercode 0x09fk4942 in KERNEL32:EXE, bitte kontaktieren sie die kostenpflichtige Technik-Hotline ;-)

Z. B. kann Win3.1 während eines Interrupts (besonders wenn auf
Disketten zugegriffen wurde, war dies höllisch lästig) nicht in ein
anderes Programm wechseln.

Oh ja, davon kann ich auch noch lieder singen *g*

dito *g*... Besonders, als ich ein TSR auf'n Timer gelegt habe, das ca. 1/20 Sekunde braucht *Schätzung* (der Timer wird alle 1/18.2 Sekunde aufgerufen)... Ei, ei, ei, ich hab noch nie solange auf den Dateimanager in Win3.1 gewartet... *g*

PS: Was meinst du zu der Aussage von Mulder?

Vollkommen korrekt. Auf aelteren Systemen war die Listen-Queue
ueberigens auf 5 Requests beschraenkt :)

lass mich raten; Comodore 64 als Webserver??? :-)

• 100 Requests/s auf ein Script möglich oder nicht?

Oh, das duerfte ziemlich stark vom System, der Anbindung und der
Plattform abhaengen.

Was? Wirklich? Krass!... *g*

Aber Prinzipiell -- warum nicht?

Öm, naja... Ich hab mir nur gedacht: Wenn mein Script 50ms braucht (exclusiv Perlinterpreter starten), dann werden 100 Scripts bereits über 1 Sekunde brauchen (bei 100% Auslastung und sequentieller Abarbeitung); wenn dann die nächste, übernächste, ... Sekunde immer noch so viele Requests hat, überläuft die Queue bzw. das System ist voll ausgelastet...

Viele Grüsse

Philipp

[Christian Kruse]

Hoi Philipp,

lass mich raten; Comodore 64 als Webserver??? :-)

Nee. Auf allen 4.2BSD-Systemen :)

Aber Prinzipiell -- warum nicht?

(bei 100% Auslastung und sequentieller Abarbeitung);

Genau das passiert aber *nicht* :)

Gruesse,
 CK

[Philipp Hasenfratz]

Halihallo Forumer

also... Die ersten Testergebnisse sind eingetroffen ;-)

$VAR1 = {
          'DiffCount' => '1000',
          'RequestsPerSecondAvarage' => '7.2992700729927',
          'DiffSentProcessed' => '1980',
          'DiffSendProcessedAvarage' => '1.98',
        }

Also ca. 7.3 Requests/Sekunde, wobei Request-Progi und Response-Progi auf'm selben Server liegen => Performanceverschlingen * 2... Nächste Testfolge mit unterschiedlichen Servern...
Na, ja, für ein Webspace, der den Computer mit ca. 500 (???) anderen webs teilt und um 17:30 => Stosszeit? - Ist naja, ganz nett...

Viele Grüsse

Philipp

[code2i]

Hallo...

erstmal Gruesse...
... konnte in Windeseile auch mal wieder schnell reinschauen!

Hallo Philipp,

ich hab noch einen alten Performance Test gefunden.

Windows NT4 SP5 PII 400MHz, 128Mbyte Thread Limit set to 100 Handlers.

Allerdings werden hier Servlets eingesetzt. Und wie schon gesagt alles ein bischen älter. Sun's JDK 1.2.2 JIT.

Eingesetzt ein TestServlet welches Header setzt und manipuliert und zusätzlich mit cookies arbeitet.... allerdings keine Sessions. Servlet Apis2.0

Ergebniss : 175 requests per second

Mit einem blöden Hello World Servlet waren 250 request per second drin.

cu

bis irgendwann mal wieder

code2i :-)

[Philipp Hasenfratz]

Halihallo code2i

erstmal Gruesse...
... konnte in Windeseile auch mal wieder schnell reinschauen!

immer wieder gerne.

ich hab noch einen alten Performance Test gefunden.
Windows NT4 SP5 PII 400MHz, 128Mbyte Thread Limit set to 100 Handlers.
Allerdings werden hier Servlets eingesetzt. Und wie schon gesagt alles ein bischen älter. Sun's JDK 1.2.2 JIT.
Eingesetzt ein TestServlet welches Header setzt und manipuliert und zusätzlich mit cookies arbeitet.... allerdings keine Sessions. Servlet Apis2.0

Ergebniss : 175 requests per second

Mit einem blöden Hello World Servlet waren 250 request per second drin.

ei, ei, ei... Ist Java so viel schneller, als Perl oder ist mein Server einfach lahm...? - Naja, wahrscheinlich ist Java einfach ein Stückchen besser, da es vorkompiliert ist und nicht "hard-core" interpretiert werden muss... Zudem handelt es sich bei meinem Test-Server nur um einen normalen Webspace, der mit anderen Webs geshared wird.

Vielen Dank für die Information! - Wir kommen der Performance langsam auf die Schliche...

Viele Grüsse

Philipp

[Klaus Mock]

Hallo,

ei, ei, ei... Ist Java so viel schneller, als Perl oder ist mein Server einfach lahm...? - Naja, wahrscheinlich ist Java einfach ein Stückchen besser, da es vorkompiliert ist und nicht "hard-core" interpretiert werden muss... Zudem handelt es sich bei meinem Test-Server nur um einen normalen Webspace, der mit anderen Webs geshared wird.

Na ich weiß nicht. Ich hab mir das gerade auf meinem Rechner angesehen. HTTP-Request in Perl mit dem Benchmark-Modul absetzen lassen (seriell), einmal auf 127.0.0.1, einmal auf die lokale Netzwerkkarte, einmal auf eine andere Maschine. Dabei forderte ich einmal statische Seiten, einmal  die Ausgabe eines einfachen Perl-Scripts an. Das ganze auf zwei Maschinen (Linux auf einem PII 450 und Win2K auf einem PIII 766). Überall Apache 1.3.x.

Bei allen kam ich auf ca. 350-450 Requests pro Sekunde. Wobei vielleicht auffällig ist, daß der schnellere unter Win2K nicht entsprechend schneller ist. ICh denke allerdings das da schon der Socket-Overhead mit hineinspielt.

Vielleicht komme ich morgen noch dazu, das Ganze einmal genauer zusammenzuschreiben und zu posten.

Grüße
  Klaus

PS: allerdings habe ich kein LWP::Simple verwendet, sondern den Request ziemlich schnörkellos gehalten.

[Philipp Hasenfratz]

Halihallo Klaus

ei, ei, ei... Ist Java so viel schneller, als Perl oder ist mein Server einfach lahm...? - Naja, wahrscheinlich ist Java einfach ein Stückchen besser, da es vorkompiliert ist und nicht "hard-core" interpretiert werden muss... Zudem handelt es sich bei meinem Test-Server nur um einen normalen Webspace, der mit anderen Webs geshared wird.

Na ich weiß nicht. Ich hab mir das gerade auf meinem Rechner angesehen. HTTP-Request in Perl mit dem Benchmark-Modul absetzen lassen (seriell), einmal auf 127.0.0.1, einmal auf die lokale Netzwerkkarte, einmal auf eine andere Maschine. Dabei forderte ich einmal statische Seiten, einmal  die Ausgabe eines einfachen Perl-Scripts an. Das ganze auf zwei Maschinen (Linux auf einem PII 450 und Win2K auf einem PIII 766). Überall Apache 1.3.x.

Hm. Seriell. Ich kann mir zwar nicht ausdenken, dass es grad um den Faktor 35x ändert ( 10 => 350 ), aber die serielle Verarbeitung wird sicher Konsequenzen haben. Da jedoch beim Webserver die Anfragen wohl kaum seriell ankommen, halte ich die Lösung mit fork für "wirklichkeitsnäher". Würde mich interessieren, ob du auf dieselbe Verarbeitungsgeschwindigkeit kommst mit fork.

PS: allerdings habe ich kein LWP::Simple verwendet, sondern den Request ziemlich schnörkellos gehalten.

Was meinst du mit schnörkellos? - Ohne "unnötige" Headerdaten vom LWP::UserAgent? - Also "GET ... HTTP/1.0\015\012\015\012" ohne was anderes?

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo Forumer

Ein herzliches Dankeschön an Andreas Korthaus, der mir beim analysieren und den Server-Attacken sehr geholfen hat. Er hat seine Rechner auf meinen losgehetzt und ihn wohl auch ziemlich zum schwitzen gebracht :-)
Zudem hat er einige eigene Programme dafür programmiert und diese mit meinen zusammen laufen gelassen => Auslastung pur...

Wir kamen bisher auf maximal 32 Requests/Sekunde. Der Durchschnitt pendelt sich etwa bei 11-13 Requests/Sekunde ein.

Viele Grüsse und vielen Dank an alle

Philipp

[Andreas]

Hallo!

Ein herzliches Dankeschön an Andreas Korthaus, der mir beim analysieren und den Server-Attacken sehr geholfen hat. Er hat seine Rechner auf meinen losgehetzt und ihn wohl auch ziemlich zum schwitzen gebracht :-)

*schäm* mußte das sein ... *schäm*

;-)

Zudem hat er einige eigene Programme dafür programmiert und diese mit meinen zusammen laufen gelassen => Auslastung pur...

Wir kamen bisher auf maximal 32 Requests/Sekunde. Der Durchschnitt pendelt sich etwa bei 11-13 Requests/Sekunde ein.

Aber nur wegen meinem blöden provider der alle killt was ihm zu schnell vorkommt ;-) aber ich habe die Shell noch nicht ausgereitzt...

Aber wirklich, mach ich doch gerne und macht mir doch Spaß! Nur das ich heute hätte lernen sollen... aber egal, hab halt andere Sachen gelernt ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo ;-)

Ein herzliches Dankeschön an Andreas Korthaus, der mir beim analysieren und den Server-Attacken sehr geholfen hat. Er hat seine Rechner auf meinen losgehetzt und ihn wohl auch ziemlich zum schwitzen gebracht :-)

*schäm* mußte das sein ... *schäm*
;-)

Ja! :-)

Zudem hat er einige eigene Programme dafür programmiert und diese mit meinen zusammen laufen gelassen => Auslastung pur...

Wir kamen bisher auf maximal 32 Requests/Sekunde. Der Durchschnitt pendelt sich etwa bei 11-13 Requests/Sekunde ein.
Aber nur wegen meinem blöden provider der alle killt was ihm zu schnell vorkommt ;-) aber ich habe die Shell noch nicht ausgereitzt...

Aber wirklich, mach ich doch gerne und macht mir doch Spaß! Nur das ich heute hätte lernen sollen... aber egal, hab halt andere Sachen gelernt ;-)

Ich hab dich ja genug oft daran erinnert, aber du warst einfach nicht zu stoppen :-)
Ne, ganz im Ernst: Hast mir sehr geholfen und dafür bin ich dir sehr dankbar. Ich werd dann nachher nochmals einige Tests laufen lassen; derzeit verbessere ich grad noch das Multi-Server-Attack-Progi :-)
Ich will umbedingt, dass das Rechenzentrum heut noch in Flammen steht und dass ich morgen den Erfolg der Programme an den Einschaltquoten von CNN (Meldung: die grösse Rechenzentrum Katastrophe seit es Computer gibt) messen kann :-)

Viele Grüsse

Philipp

[Michael Schröpl]

Hallo Philipp,

Ich muss eine Serverseitige Anwendung programmieren,
um die Anzahl der Benutzer zu analysieren (bzw. zu
speichern).

mir erschließt sich der Zusammenhang zwischen beiden
Aussagen nicht.

Ich muß auf unserer Serverfarm auch die Anzahl der
Benutzer analysieren - aber ich habe dafür keine
Anwendung geschrieben, sondern den Apache verwendet.

Die Information, die einen Benutzer eindeutig
identifiziert, ist in meinem Fall ein HTTP-Header.
Um diesen auf dem Server auszuwerten, brauche ich
keine serverseitige Anwendung. Ich definiere im
Apache einfach eine separate Log-Datei, und deren
Format ist frei definierbar - insbesondere kann man
HTTP-Header eigener Wahl als Formatfelder verwenden.

Einmal am Tag wird diese Log-Datei "gerollt" und danach
(wenn der Apache wieder läuft) durch ein beliebig
langsames Perl-Skript ausgewertet.

Warum sollte ich versuchen, mit dem Apache zu
konkurrieren, wenn ich ihn auch verwenden kann?

Viele Grüße
      Michael

[Andreas]

Hi!

mir erschließt sich der Zusammenhang zwischen beiden
Aussagen nicht.

Ich muß auf unserer Serverfarm auch die Anzahl der
Benutzer analysieren - aber ich habe dafür keine
Anwendung geschrieben, sondern den Apache verwendet.

Das hatte ich auch(so ähnlich) vorgeschlagen, aber Phillipp will ja nicht den Apache selbst testen, sondern das PERL-Script. Das Script was jetzt läuft dprfte ähnlich schnell sein, und wie es aussieht schafft er auf die Dauer nur ca. 12 Requests pro Sekunde.

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Phillipp will ja nicht den Apache selbst testen,
sondern das PERL-Script.

Für mich klang das nicht so - er hat eine Lösung, aber
eine Alternative ggf. noch gar nicht in Erwägung gezogen.

Das Script was jetzt läuft dürfte ähnlich schnell
sein, und wie es aussieht schafft er auf die Dauer
nur ca. 12 Requests pro Sekunde.

Das Skript ist bestimmt langsamer als der Server alleine

• ich schätze, um mindestens eine Zehnerpotenz.

Viele Grüße
      Michael

[Andreas]

Hallo!

Für mich klang das nicht so - er hat eine Lösung, aber
eine Alternative ggf. noch gar nicht in Erwägung gezogen.

Wie meinst Du das? Eine Alternative zu welcher Lösung? Das Script soll halt austesten, wei belastbar das eigentliche Perl-Programm später sein wird, und ab wann man evtl was an der Hardware ändern muß. Angenommen wir bekommen jetzt tatsächlich 12 aöls gernze, dann müßte er ja wenn er sich im Betrieb nur annähernd bei den peaks in diese Richtung bewegt schnell für einen leistungsfähigeren Server sorgen, oder balancing...

Das Script was jetzt läuft dürfte ähnlich schnell
sein, und wie es aussieht schafft er auf die Dauer
nur ca. 12 Requests pro Sekunde.

Das Skript ist bestimmt langsamer als der Server alleine

• ich schätze, um mindestens eine Zehnerpotenz.

Aber wie testet man den Sever selbst? ich habe mal nur html-Abgafragt, ist kurzfristig etwa 3 mal so schnell(70 Requests/Sekunde), aber nach 1000 Requests geht das dermaßen in die Knie...
Zumindest bekomt mein Script kurzfristig gar keine Verbindung, aber nach 20-30 Sekunden geht es schneller weiter als zuvor?! Etwas seltsam, perl schafft die ersten 10 Sekunden ca. 20/sekunde, dannach konstant knapp 12.

Aber wenn ich andere Server "messe" , z.B. php.net/links.php habe ich konstatn werte von 4-5/Sekunde! Also kann es eigentlich nicht an meinem Server liegen, vor allem schaffe ich kurzfristig(einige Sekunden) über 100. Vermutlich ist da tatsächlich eine Warteschlange die erst abgearbeite werden muß ;-)
Aber wo ist die Warteschlange genau? "vor" PERL?

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Wie meinst Du das? Eine Alternative zu welcher
Lösung? Das Script soll halt austesten, wie
belastbar das eigentliche Perl-Programm später
sein wird

eben dieses "eigentliche Perl-Programm" (zur Erfassung
der Daten, nicht zur Auswertung) ist ggf. überflüssig.

Das Skript ist bestimmt langsamer als der Server
alleine - ich schätze, um mindestens eine
Zehnerpotenz.
Aber wie testet man den Sever selbst? ich habe mal
nur html-Abgafragt, ist kurzfristig etwa 3 mal so
schnell(70 Requests/Sekunde), aber nach 1000
Requests geht das dermaßen in die Knie...

Mach einen HTTP-HEAD-request, der ist schneller.

Aber wo ist die Warteschlange genau? "vor" PERL?

Im Netzwerk? Beim Erweitern des Pools der Apache-
Prozesse? Einen hochperformanten Webserver aufzubauen
ist eine nicht ganz triviale Aufgabe.

Viele Grüße
      Michael

[Philipp Hasenfratz]

Halihallo Michael

Ich muss eine Serverseitige Anwendung programmieren,
um die Anzahl der Benutzer zu analysieren (bzw. zu
speichern).

mir erschließt sich der Zusammenhang zwischen beiden
Aussagen nicht.

die erste Anwendung führt eine pre-analyse durch; das zweite (und für den Kunden sichtbare) die Reportgenerierung (was ja auch eine Analyse ist).

Ich muß auf unserer Serverfarm auch die Anzahl der
Benutzer analysieren - aber ich habe dafür keine
Anwendung geschrieben, sondern den Apache verwendet.
Die Information, die einen Benutzer eindeutig
identifiziert, ist in meinem Fall ein HTTP-Header.
Um diesen auf dem Server auszuwerten, brauche ich
keine serverseitige Anwendung. Ich definiere im
Apache einfach eine separate Log-Datei, und deren
Format ist frei definierbar - insbesondere kann man
HTTP-Header eigener Wahl als Formatfelder verwenden.

Da bin ich einverstanden. Das wäre in der Tat eine Lösung, um die Pageviews zu messen. Nur leider ist die Messung nicht nur auf Pageviews beschränkt, sondern misst auch noch weiteres, was nicht durch den Apachen ausgewertet werden kann, da die Analyse auf Datenstrukturen der Webapplikation zurückgreift. Deswegen bin ich auf ein Script angewiesen und somit greift dann auch die Antwort von Andreas, dass ich die Geschwindigkeit des Apachen/Perl-Script messen muss.

Einmal am Tag wird diese Log-Datei "gerollt" und danach
(wenn der Apache wieder läuft) durch ein beliebig
langsames Perl-Skript ausgewertet.

das funktioniert bei uns analog. Der "tag" (also das Script von dem wir sprechen), analysiert die Daten nicht zu Ende, da die Interpretation der Daten einen Datenbankzugriff voraussetzen, den ich bewusst nicht in das Script implementiert habe.
Die endgültige Auswertung wird über einen "cron-job gestartetes Script" übernommen; die Reportgenerierung ist natürlich vom Benutzer abhängig.

Warum sollte ich versuchen, mit dem Apache zu
konkurrieren, wenn ich ihn auch verwenden kann?

das würde ich nie wagen ;-)

Viele Grüsse

Philipp

[Andreas]

Hallo!

HTTP-Header eigener Wahl als Formatfelder verwenden.

Nur leider ist die Messung nicht nur auf Pageviews beschränkt, sondern misst auch noch weiteres, was nicht durch den Apachen ausgewertet werden kann, da die Analyse auf Datenstrukturen der Webapplikation zurückgreift. Deswegen bin ich auf ein Script angewiesen und somit greift dann auch die Antwort von Andreas, dass ich die Geschwindigkeit des Apachen/Perl-Script messen muss.

Nicht unbedingt! Du kannst ja so ziemlich alles loggen! Die Auswertung kann dann später erfolgen, dadurch erhöhst Du Deine Leistungsfähigkeit um ein vielfaches! Du loggst alle Zugriffe(Du kannst ja so ziemlich alles loggen, was Du zur Laufzeit im PERL-Script auswerten könntest) durch den Apache, auch den Request-String ggfs. mit Parametern, später um 4:00 morgens kann das dann ein PERL-Script per Cron analysieren. Spar Dir doch den einen Zwischenschritt da dieser Deine Perfomrance extremst ausbremst!

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

HTTP-Header eigener Wahl als Formatfelder verwenden.

Nur leider ist die Messung nicht nur auf Pageviews beschränkt, sondern misst auch noch weiteres, was nicht durch den Apachen ausgewertet werden kann, da die Analyse auf Datenstrukturen der Webapplikation zurückgreift. Deswegen bin ich auf ein Script angewiesen und somit greift dann auch die Antwort von Andreas, dass ich die Geschwindigkeit des Apachen/Perl-Script messen muss.

Nicht unbedingt!

aber in diesem Falle aber schon ;-)

Du kannst ja so ziemlich alles loggen! Die Auswertung kann dann später erfolgen, dadurch erhöhst Du Deine Leistungsfähigkeit um ein vielfaches! Du loggst alle Zugriffe(Du kannst ja so ziemlich alles loggen, was Du zur Laufzeit im PERL-Script auswerten könntest)

Cookies, die an den Server gesendet wurden? - Wenn ja, dann hab ich ein weiteres Problem: Ich hab (zumindest derzeit) keinen Zugriff auf die Konfigurationen.

durch den Apache, auch den Request-String ggfs. mit Parametern, später um 4:00 morgens kann das dann ein PERL-Script per Cron analysieren. Spar Dir doch den einen Zwischenschritt da dieser Deine Perfomrance extremst ausbremst!

Das versuche ich bereits nach bestem Wissen und bester Möglichkeit. Dadurch konnte ich die Performance schon wesentlich verbessern (man denke nur an die mysql-Datenbankzugriffe, die wegfallen).

Viele Grüsse

Philipp

[Andreas]

hi!

Cookies, die an den Server gesendet wurden? - Wenn ja, dann hab ich ein weiteres Problem: Ich hab (zumindest derzeit) keinen Zugriff auf die Konfigurationen.

Du wirst jawohl nicht die Besucher Deiner Kunden zwingen einen externen Cookie zu akzeptieren, oder? Das ist nicht gut, da da die meisten Browser meckern!
Ich weiß jetzt nicht genau was die Kunden bei sich einbinden müssen aber welche Daten ziehst Du aus dem Cookie, abgesehen davon das es nicht erlaubt ist Cookies außer Sessioncookies ohne Vorwarnung zu setzen!

durch den Apache, auch den Request-String ggfs. mit Parametern, später um 4:00 morgens kann das dann ein PERL-Script per Cron analysieren. Spar Dir doch den einen Zwischenschritt da dieser Deine Perfomrance extremst ausbremst!

Das versuche ich bereits nach bestem Wissen und bester Möglichkeit. Dadurch konnte ich die Performance schon wesentlich verbessern (man denke nur an die mysql-Datenbankzugriffe, die wegfallen).

Aber sauber mit den 10.000 flat-files ist das auch nicht. Vor allem warum machst du rand()? ich würde evtl microtime() verwenden, halt für jeden zugriff ne exra file, und am Ende alle Dateiname in dem Verzeichnis in einen Array laden und dann in einer Schleife die Dateien auslesen und in MySQL schreiben und löschen! Bei einem Request pro Sekunde hättest Du gerade mal gut doppelt so viele files wie mit Deinem System, mit dem Unterschied das das mit dem Zeitpunkt sehr viel genauer ist! Immerhin passen dann statt 12 Requests 1 Mio Request in eine Sekunde, wenn Du in die Region kommst ist Bill Gates gegen Dich ein Gartenzwerg ;-) Aber wenn Du Angst hast das trotzdem eng wird kannst Du ja noch rand dazu nehmen, und den String noch länger machen ;-)

Aber bestünde nicht die Möglichkeit das Du die Cookiedaten irgendwie in den Request bekommst? Ich meine die Daten sind ja schon auf der Homepage da, aber Du kannst wahrscheinlich an dieser Stelle keine Scriptsprache verwenden, oder?
am besten wäre ein transparentes gif welches geladen wird und der Apache einen Eintrag in einer angepassten Log macht. Aber das reicht nicht, oder?

Aber was müssen die Leute bei sich einbindn, damit überhaupt was geloggt wird?

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Cookies, die an den Server gesendet wurden? - Wenn ja, dann hab ich ein weiteres Problem: Ich hab (zumindest derzeit) keinen Zugriff auf die Konfigurationen.

Du wirst jawohl nicht die Besucher Deiner Kunden zwingen einen externen Cookie zu akzeptieren, oder? Das ist nicht gut, da da die meisten Browser meckern!

Das ist mir bewusst. Aber die Statistik fordert es. Entschuldigung, aber darüber lass ich nicht mit mir streiten; es ist so und so muss es einfach akzeptiert werden! - Ich bin ja sonst nicht so abweisend, aber hier bringt's wirklich nix, wenn man mir sagt, dass dieses Cookie Zeug schlecht ist. Mich regen die Cookies auch auf und mir ist bewusst, dass sich Cookies deaktivieren lassen.
Nennen wir diese Cookie-Geschichte einfach Axiom der Webapplikation. Axiome sind Grundeigenschaften, die sich nunmal nicht ändern lassen.

Ich weiß jetzt nicht genau was die Kunden bei sich einbinden müssen aber welche Daten ziehst Du aus dem Cookie, abgesehen davon das es nicht erlaubt ist Cookies außer Sessioncookies ohne Vorwarnung zu setzen!

Es sind "Sessioncookies". Eindeutige Identifikation der Kunden. Entschuldige, aber ich darf hierzu nicht mehr sagen, zumindest nicht bevor wir am Markt etabliert sind. Ich darf hierzu keine Internas preisgeben (ich würde zwar gerne...).

durch den Apache, auch den Request-String ggfs. mit Parametern, später um 4:00 morgens kann das dann ein PERL-Script per Cron analysieren. Spar Dir doch den einen Zwischenschritt da dieser Deine Perfomrance extremst ausbremst!

Das versuche ich bereits nach bestem Wissen und bester Möglichkeit. Dadurch konnte ich die Performance schon wesentlich verbessern (man denke nur an die mysql-Datenbankzugriffe, die wegfallen).

Aber sauber mit den 10.000 flat-files ist das auch nicht. Vor allem warum machst du rand()? ich würde evtl microtime() verwenden, halt für jeden zugriff ne exra file, und am Ende alle Dateiname in dem Verzeichnis in einen Array laden und dann in einer Schleife die Dateien auslesen und in MySQL schreiben und löschen!

Das funktioniert auch genau so (nur eben mit rand) :-)
Warum rand? - Weil microtime 1) nicht gibt in perl (Time::HiRes wäre hier vielleicht brauchbar) und 2) weil rand auch bei zwei gleichzeitig eintreffenden Requests mit sehr grosser Wahrscheinlichkeit eine völlig andere Zahl liefert, was bei microtime nicht der Fall wäre.
Zudem sind die 10'000 Dateien nur dazu da das Request-Logging auf verschiedene Dateien zu verteilen, um so den Traffic auf eine Datei kleinzuhalten, sodass sich die Prozesse nicht in die Haare kriegen. Natürlich wird auch bei jeder Datei noch gelockt und entlockt; aber wenn man die Requests auf verschiedene Dateien verteilt, ist die Wahrscheinlichkeit kleiner, dass überhaupt der Zugriff auf eine Datei verweigert wird, wenn sie von einem anderen Prozess bearbeitet wird. Na, ja, ihr seht, ich hab das so Programmiert, dass ich auch bei 1'000'000 Requests pro Sekunde gute Karten habe :-))

Bei einem Request pro Sekunde hättest Du gerade mal gut doppelt so viele files wie mit Deinem System, mit dem Unterschied das das mit dem Zeitpunkt sehr viel genauer ist! Immerhin passen dann statt 12 Requests 1 Mio Request in eine Sekunde, wenn Du in die Region kommst ist Bill Gates gegen Dich ein Gartenzwerg ;-) Aber wenn Du Angst hast das trotzdem eng wird kannst Du ja noch rand dazu nehmen, und den String noch länger machen ;-)

Natürlich wäre es möglich für jeden Request eine eigene Datei anzulegen (als unique-filenames generieren), aber das halte ich für etwas übertrieben... Ich will ja nicht Statistiken über das ganz Web anlegen :-)
Ich will dem Billi nicht mal konkurrieren :-)

Aber bestünde nicht die Möglichkeit das Du die Cookiedaten irgendwie in den Request bekommst? Ich meine die Daten sind ja schon auf der Homepage da, aber Du kannst wahrscheinlich an dieser Stelle keine Scriptsprache verwenden, oder?

genau. Der Kunde soll keine Scripts bei sich installieren müssen, oder sonstige Spässe über sich ergehen lassen. Das einzige was er soll, ist ein simpler Tag in seine Page setzen; da der Cookie von meinem Progi generiert wird, wird er auch nur für meine Domain sichtbar => mit JS auf dem Kundenserver ist da auch nix zu machen.

am besten wäre ein transparentes gif welches geladen wird und der Apache einen Eintrag in einer angepassten Log macht. Aber das reicht nicht, oder?

Was ich brauche ist eigentlich nur die aktuelle Zeit und der Cookie. Dürfte also mit dem angepassten Log machbar sein. Ich denke, dass ich dies auch machen werde, wenn die Serverfarm steht und ich Zugriff auf die Konfig hab.

Aber was müssen die Leute bei sich einbindn, damit überhaupt was geloggt wird?

Ein kleiner HTML-Code mit JS-Script Einbindung (dass der eigentliche Referer der Kundenwebsite eingebunden werden kann; und eine Timestamp an das Bild angehängt wird, um das Client-Caching möglichst zu verhindern) und einem transparenten <img>, das auf das tag-script auf meinem Server zeigt.

Viele Grüsse

Philipp

[Michael Schröpl]

Haloo Philipp,

HTTP-Header eigener Wahl als Formatfelder
verwenden.
Nur leider ist die Messung nicht nur auf
Pageviews beschränkt, sondern misst auch
noch weiteres, was nicht durch den Apachen
ausgewertet werden kann, da die Analyse auf
Datenstrukturen der Webapplikation
zurückgreift.

brauchst Du die Analyse in Echtzeit?

Ich möchte nur vorschlagen, den Apache für die
Datenerfassung zu verwenden. Es reicht völlig, wenn Du
diesem einen HTTP-HEAD-Request sendest - und das geht
innerhalb einer Sekunde ziemlich oft.

Du kannst ja so ziemlich alles loggen!
Die Auswertung kann dann später erfolgen,
dadurch erhöhst Du Deine Leistungsfähigkeit um
ein vielfaches!

Genau das war die Idee.

Cookies, die an den Server gesendet wurden?

Auch.
(Das ist übrigens der konkrete Einsatzfall bei mir.)

Aber "beliebige HTTP-Header" war wörtlich gemeint.

durch den Apache, auch den Request-String ggfs.
mit Parametern, später um 4:00 morgens kann das
dann ein PERL-Script per Cron analysieren. Spar
Dir doch den einen Zwischenschritt da dieser
Deine Perfomrance extremst ausbremst!
Das versuche ich bereits nach bestem Wissen und
bester Möglichkeit. Dadurch konnte ich die
Performance schon wesentlich verbessern (man denke
nur an die mysql-Datenbankzugriffe, die wegfallen).

Ich dachte insbesondere daran, daß Du bisher irgendwas
programmieren mußt, was Deine Schreibzugriffe synchro-
nisiert. Auch das nimmt Dir der Apache ab.

Viele Grüße
      Michael

[Philipp Hasenfratz]

Halihallo Michael

HTTP-Header eigener Wahl als Formatfelder
verwenden.
Nur leider ist die Messung nicht nur auf
Pageviews beschränkt, sondern misst auch
noch weiteres, was nicht durch den Apachen
ausgewertet werden kann, da die Analyse auf
Datenstrukturen der Webapplikation
zurückgreift.

brauchst Du die Analyse in Echtzeit?

Nein. Vom Request zum Report vergehen auch jetzt bis zu einem Tag. Ich habe ja mehrere Statistikserver, die dann die Daten pre-analysiert und kodiert auf den Hauptserver übertragen, wo sie in der mysql-DB gespeichert werden; erst dann sind die Daten für das Reporting "sichtbar". Die Synchronisation geschieht natürlich immer in der Nacht => alle 24 Stunden.

Cookies, die an den Server gesendet wurden?

Auch.
(Das ist übrigens der konkrete Einsatzfall bei mir.)
Aber "beliebige HTTP-Header" war wörtlich gemeint.

Aha! - Jetzt wird's interessant (jetzt begreife ich langsam, was der Apache alles kann ;))... Also jeder beliebige Header vom HTTP-Request kann geloggt werden, also natürlich auch der Set-Cookie: - Header... Das wäre in der Tat eine Lösung; so könnte es wirklich funktionieren.

durch den Apache, auch den Request-String ggfs.
mit Parametern, später um 4:00 morgens kann das
dann ein PERL-Script per Cron analysieren. Spar
Dir doch den einen Zwischenschritt da dieser
Deine Perfomrance extremst ausbremst!
Das versuche ich bereits nach bestem Wissen und
bester Möglichkeit. Dadurch konnte ich die
Performance schon wesentlich verbessern (man denke
nur an die mysql-Datenbankzugriffe, die wegfallen).

Ich dachte insbesondere daran, daß Du bisher irgendwas
programmieren mußt, was Deine Schreibzugriffe synchro-
nisiert. Auch das nimmt Dir der Apache ab.

Das glaube ich jetzt weniger. Er nimmt mir vielleicht die Übertragung der Daten ab, jedoch nicht das Auswerten; die Daten sollen ja schon pre-analysiert auf den Server übertragen werden; die Analyse und Bearbeitung der Daten ist nicht so einfach, als dass sie durch ein "Standardprozedere" gemacht werden könnten; ein bischen muss ich da schon noch programmieren. Aber das wäre ja auch kein Problem, dieses Script läuft ja nur einmal/Tag.

Zum Apache-Log:
Ich finde diesen Lösungsvorschlag sehr interessant. Hättest vielleicht jemand grad einen guten Link zur Hand, wo ich mehr über die Konfiguration des Apache-Logs herausfinden kann? - Ich würde mich zu diesem Lösungsvorschlag gerne etwas näher befassen. Im Moment kann ich diesen Vorschlag jedoch nicht umsetzen, da wir, wie ich bereits gesagt habe, keine Berechtigung auf die Konfiguration haben; aber wenn die eigene Serverfarm steht; würde ich gerne hier weitermachen mit dieser Lösung; kann ja schon mal offline testen.
Eigentlich könnte ich dann auch ein C-Progi schreiben, dass einen bestimmten Port als Daemon abhört und nur dazu dient, die HTTP-Requests auf das eine tag-script (was dann aber gar nimmer existiert) zu loggen; das wäre vielleicht sogar noch schneller als Apache (wenn auch minimal)... Aber man muss es ja nicht übertreiben, zudem müsste ich dann erst wirklich mal C lernen...
Das einzige, was mir an dieser Lösung nicht gefällt ist, dass ich auf den Apache angewiesen bin. Ich hatte bisher die Applikation so programmieren wollen, dass sie in den meisten Webservern und OS läuft; damit würde ich dieses Konzept verlassen... Aber aufgrund der Performance halte ich diesen Verstoss für vertretbar.

Viele Grüsse und danke für den Input

Philipp

[Philipp Hasenfratz]

Halihallo Michael

Zum Apache-Log:
Ich finde diesen Lösungsvorschlag sehr interessant. Hättest vielleicht jemand grad einen guten Link zur Hand, wo ich mehr über die Konfiguration des Apache-Logs herausfinden kann?

http://httpd.apache.org/docs/mod/mod_log_config.html#cookielog
http://httpd.apache.org/docs/mod/mod_usertrack.html
http://www.google.ch/search?hl=de&ie=ISO-8859-1&q=Apache+Log+Cookie&btnG=Google-Suche&meta=

so, ich denke, dass ich alles Wichtige gefunden habe. Nochmals Danke für den Tipp.

Viele Grüsse

Philipp