Auslastung eines Servers

[Michael]

Hallo,
ich habe eine normale HTML Seite mit einen Form (ca 30 Textfeldern) und eine PHP Seite die die Anfragen( schreibt Daten nur in ein Textfeld) bearbeitet. Nun sollen sich aber ca 200.000 Leute innerhalb von zwei Wochen anmelden.

Reicht eine einziger Server aus, sagen wir ein Celeron mit 1,2 Ghz ?
Oder wieviele Rechner brauche ich um diese Menge zu bewältigen ?

Hat jemand damit Erfahrung oder weiss jemand wieviel man einem Server der mit PHP Seiten arbeitet zumuten kann um noch akzeptable Zugriffszeiten zu bekommen.

Wie ist den der Aufbau dieses Forums, hat er auch mehrere Rechner um die Last zu verteilen ?

Gruss Michael

[Till]

Hallo Michael

was wird denn genau gemacht?
   nur die daten in eine db eingetragen?

ich habe eine meiner toplisten mal unter maximalen bedingungen
   gestest und da konnten ohne probleme jede sec ein eintrag 24
   stunden lang eingetragen werden...wo hast du den server oder ist
   es dein rechner?
   wenn ja was hast du für einen upstream?

[Michael]

Hallo Michael

was wird denn genau gemacht?
   nur die daten in eine db eingetragen?

nein, wie schon erwähnt direkt in eine Textdatei

ich habe eine meiner toplisten mal unter maximalen bedingungen
   gestest und da konnten ohne probleme jede sec ein eintrag 24
   stunden lang eingetragen werden...

Ja, aber bei mit werden es wohl ca 50 pro sec.

wo hast du den server oder ist es dein rechner?
   wenn ja was hast du für einen upstream?

Wird bei Schlund und Partner stehen, die Anbindung wird auf jeden Fall ausreichen.

Wie stark ist denn die Auslastung der CPU bei einem PHP-Script. Gibt es dort eine Fausformel oder sowas ?

Gruss Michael

[lulu]

Huhu Michael

Wird bei Schlund und Partner stehen, die Anbindung wird auf jeden Fall ausreichen.

Wenn ich mich recht erinnere gibt es bei Schlund auf der Service-Seite
Infos über die Beschränkungen (je nach Tarif).

Z.B. max. 12 DB-Prozesse; 18 PHP-Prozesse gleichzeitig.

Da solltest Du mal recherchieren was Dir zur Verfügung steht.
(Die haben ja auch eine kostenlosen 0800 - Support)

Viele Grüße

lulu

[Till]

öhm wird bei deinem script die datei gehast und dann der datenzeiger ans ende gesetzt wenn ja sag ich dir vergiss es...
schonmal ne txt datei mit 100000 zeilen geöfnet?

[Michael]

öhm wird bei deinem script die datei gehast und dann der datenzeiger ans ende gesetzt wenn ja sag ich dir vergiss es...
schonmal ne txt datei mit 100000 zeilen geöfnet?

ich wollte das entweder auf mehrere Textdatein verteilen pro Stunde eine oder es vielleicht doch in eine mySQL Datenbank speichern. Das werde ich noch testen, hast du da schon Erfahrung mit ?

Gruss
Michael

[lulu]

Huhu Michael

ich wollte das entweder auf mehrere Textdatein verteilen pro Stunde eine oder es vielleicht doch in eine mySQL Datenbank speichern. Das werde ich noch testen, hast du da schon Erfahrung mit ?

Im Rahmen eines "Cookie-Tracking" (* schäm * ich war jung und brauchte das Geld ) hatte ich zuerst genau die gleichen Überlegungen angestellt.
Ich nahm an, dass das reine Textlogging besser funktionieren würde.
Dann habe ich einen Testlauf txt-File vs. Datenbank durchgeführt.
Das lief auch auf einem Schlund-Server.
Gewonnen hat die Datenbank.

so short ....

Viele Grüße

lulu

[Till]

willst du die daten nachher auch noch editieren?

ich hätte auf jeden fall die mysql db genommen
es würde alles erleichtern...
meld dich via icq bei mir wenn du genauere erfahrungen erfahren willst...101244712

[Andreas Korthaus]

Hi lulu!

Im Rahmen eines "Cookie-Tracking" (* schäm * ich war jung und brauchte das Geld ) hatte ich zuerst genau die gleichen Überlegungen angestellt.

so eine bist Du also... ;-)

Ich nahm an, dass das reine Textlogging besser funktionieren würde.
Dann habe ich einen Testlauf txt-File vs. Datenbank durchgeführt.
Das lief auch auf einem Schlund-Server.
Gewonnen hat die Datenbank.

Das kann ich mir nicht vorstellen. Jeder der 200.000 muß immer eine neue DB.Verbindung herstellen, für eine Abfrage. Das _kann_ doch nicht so schnell sein. Was anderes wenn man alles mit einer bestehenden/persistenten Verbindung in die Datenbank schreibt, aber das geht bei Schlund vermutlich nicht, da die mit einiger Sicherheit die CGI-Version installiert haben. Ich würd es einfach mal irgendwo testen. Soll den ein eigener Server gemietet werden? Denn sonst dar fman sich die Performance ja noch mir den anderen Kunden auf einem Server teilen! Und zur Not kannst Du ja immer noch umziehen, oder Dir einen 2. Server dazu nehmen, und dann mit einem url-rewriting die Last auf beide Server verteilen. Wobei - kennt jemand hier eine schnelle Möglichkeit die User möglichst gleichmäßig zu vertrilen? Mir fiele da nur ein Blick in die Logfiles ein und bei der IP "in der Mitte" zu teilen, alle IPs kleiner auf den einen Rechner, alle anderen auf den anderen Rechner. So würde zumindest kein Schreib oder Lesezugriff auf eine Datei nötig.
Aber um nochmal auf die genannten 50 Einträge/Sekunde zurückzukommen, das wären dann bei insgesamt 200.000 Einträgen 4.000 Sekunden, also etwas mehr als 1 Stunde, ich dachte Du hast 2 Wochen?

Wobei vermutlich selbst diese Last machbar wäre, aber das solltest Du vorher testen!

Viele Grüße
Andreas

[lulu]

Huhu Andreas

zuerst mal ein kleiner Hinweis, dass das Ausgangsposting nicht von mir, sondern von Michael war.
Da scheint es hier im Thread einige Ver(w)irrungen zu geben (siehe till).

Was den Sieg der DB über das TXT-Logging angeht hätte ich auch gesagt, dass zweiteres mehr Zugriffe vertragen würde.
Der Test brachte jedenfalls ein anderes Resultat.
Vielleicht war aber auch meine Test-Methode nicht geeignet.

Die verlief folgendermassen:

Ein Skript hat auf mehreren Servern (auf physikalisch getrennten Maschinen)
jeweils ein Perl-Skript angestossen.
Dieses hat durch forking jeweils mehrere Prozesse erzeugt die eine bestimmte Anzahl von Requests an das zu testende "Opfer" geschickt haben.

Dort wurden die Anfragen mitgeloggt.

Ich habe dann durch "Nachzählen" der Logeinträge geschaut bei welcher Methode
weniger Requests verloren gegangen sind.
Bzw. durch "Schrauben" an den Werten experimentell getestet wieviele Requests ich absenden kann, ohne das es zu Verlusten kommt.

Das erscheint mir eine geeignete Test - Methode zu sein.
Da ich aber mehr "frontend"-ler als "backend"-ler bin habe ich allerdings
nicht wirklich tiefgehende Kenntnisse auf diesem Gebiet.

so short ...

Viele Grüße

lulu

[Andreas Korthaus]

Hi!

zuerst mal ein kleiner Hinweis, dass das Ausgangsposting nicht von mir, sondern von Michael war.

Das war schon klar, ist ne schlechte Angewohnheit von mir nicht klarzumachen mit wem ich jetzt "spreche" ;-)

Ein Skript hat auf mehreren Servern (auf physikalisch getrennten Maschinen)
jeweils ein Perl-Skript angestossen.
Dieses hat durch forking jeweils mehrere Prozesse erzeugt die eine bestimmte Anzahl von Requests an das zu testende "Opfer" geschickt haben.

Dort wurden die Anfragen mitgeloggt.

Ich habe dann durch "Nachzählen" der Logeinträge geschaut bei welcher Methode
weniger Requests verloren gegangen sind.
Bzw. durch "Schrauben" an den Werten experimentell getestet wieviele Requests ich absenden kann, ohne das es zu Verlusten kommt.

Das erscheint mir eine geeignete Test - Methode zu sein.

Ich kenne mich da auch nicht so aus, hatte das nur angemommen da man mir immer gesagt hat das der Verbidnugsaufbau zur Datenbank das teuerste an der ganzen Angelegenheit ist.

Da ich aber mehr "frontend"-ler als "backend"-ler bin habe ich allerdings
nicht wirklich tiefgehende Kenntnisse auf diesem Gebiet.

ich ja auch nicht, wie es aussieht noch weniger als Du ;-)

Grüße
Andreas

[Michael]

Aber um nochmal auf die genannten 50 Einträge/Sekunde zurückzukommen, das wären dann bei insgesamt 200.000 Einträgen 4.000 Sekunden, also etwas mehr als 1 Stunde, ich dachte Du hast 2 Wochen?

ja, das ist richtig ! Ich habe mich da ein wenig verrechnet. War schon spät abends, kam mir auch ein wenig viel vor...

Aber Lulu hat mich ja korrigiert, danke !

Michael

[lulu]

Huhu Michael

Nun sollen sich aber ca 200.000 Leute innerhalb von zwei Wochen anmelden.

Sollen oder wollen ? ;-)

Wenn man das mal grob ausrechnet hast Du bei einer linearen Verteilung
200.000 / 2 / 7 / 24 / 60 rund 10 Zugriffe pro Minute.

Die Verteilung ist natürlich nie linear, und hängt stark von Deiner Zielgruppe ab.
Evtl. hast Du bereits irgendwelche Zugriffslogfiles anhand derer Du die
Verteilung über den Tag abschätzen kannst.

Wenn man bei Deinem Beispiel bleibt und mal annimmt, dass 80% der Zugriffe
sich auf 2 Stunden des Tages verteilen wären das dann

(200.000 *.8)/ 2 / 7 / 2 / 60

rund 96 Zugriffe pro Minute.

Das sollte zu schaffen sein.

Viele Grüße

lulu

[Michael]

Huhu Michael

Nun sollen sich aber ca 200.000 Leute innerhalb von zwei Wochen anmelden.

Sollen oder wollen ? ;-)

es werden soviele, ist eine Veranstaltung !!!

Wenn man bei Deinem Beispiel bleibt und mal annimmt, dass 80% der Zugriffe
sich auf 2 Stunden des Tages verteilen wären das dann

(200.000 *.8)/ 2 / 7 / 2 / 60

rund 96 Zugriffe pro Minute.

Das sollte zu schaffen sein.

von einem Server ? Celeron 1,2Ghz ? Das wäre gut...

Gruss Michael

[lulu]

Huhu Michael

Nun sollen sich aber ca 200.000 Leute innerhalb von zwei Wochen anmelden.
es werden soviele, ist eine Veranstaltung !!!

Jetzt bin ich aber neugierig, was ist das denn für eine Veranstaltung?
Und da muss man sich über das Internet anmelden und ein Formular mit 30! Feldern ausfüllen?

Aber vermutlich darfst Du das noch nicht verraten, oder?

Viele Grüße

lulu

[Michael]

Huhu Michael

Nun sollen sich aber ca 200.000 Leute innerhalb von zwei Wochen anmelden.
es werden soviele, ist eine Veranstaltung !!!

Jetzt bin ich aber neugierig, was ist das denn für eine Veranstaltung?
Und da muss man sich über das Internet anmelden und ein Formular mit 30! Feldern ausfüllen?

Aber vermutlich darfst Du das noch nicht verraten, oder?

ja, leider !!!

Michael

[Thomas Schmieder]

HuLu HuMi,
HuAll,

das sind ohne Kenntnisse über die Seiten natürlich alles nur Milchmädchenrechnungen. Wir haben gerade gestern mal ein paar Perfomance-Checks mit MySQL gemacht. Könnte mir ja vorstellen, dass da eine Datenbank im Hintergrund läuft, um die Useranmeldungen zu verwalten.

Alleine der Unterschied zwischen einem Feld VarChar(90) und TiniText (auch nur 90 Zeichen benutzt) beide mit Index belegt, haben einen mittleren Performance-Unterschied von Faktor 77 gebracht. Also VarChar war schneller.

Der Datenbank-Erstzugriff hat für eine limite Liste von 1000 aus 10.000 bei TinyText 0,8796s betragen und bei VarChar 0,2215s. Mit Index lagen die Werte beim Erstzugriff bei 0,27 und 0,07s, beim Zweitzugriff von 0,07 bis 0,27 steigend und 0,016 bis ca 0,027s steigend, je nachdem, wie hoch der Offset des Limit-Bereiches war. Verwendet wurde ein Athlon500 mit 265MB/100, IDE-System

Der Zugriff auf einen einzelnen gezielten Datensatz ist bei VarChar mit Index noch sehr viel schneller gewesen. Hier muss MySQL ja keine Kette aufbauen. Das Wegschreiben kann dann allerdings nochmals richtig Zeit kosten wegen der Aktualisierung der Indexe.

rund 96 Zugriffe pro Minute.

Das wären dann vielleicht ca. 2 bis 5 Sekunden. Die Scriptausführung in PHP schlägt je nach Funktionstiefe nochmals mit ca. 10 bis 20% zu Buche.

Das sollte zu schaffen sein.

Das mag ich allerdings unterschreiben. Das würde selbst ein 80386 mit 128MB und SCSI-System schaffen (gibts nicht, weiß ich). Aber so ein alter Pentium 120 mit 7200er SCSI-Platte, der würde selbst die zehnfache Last noch gerade so wegstecken.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Andreas Korthaus]

Hallo!

das sind ohne Kenntnisse über die Seiten natürlich alles nur Milchmädchenrechnungen. Wir haben gerade gestern mal ein paar Perfomance-Checks mit MySQL gemacht. Könnte mir ja vorstellen, dass da eine Datenbank im Hintergrund läuft, um die Useranmeldungen zu verwalten.

hier geht es ja nur um eine Anmeldephase, daher würde ich das so performant wie möglich machen, also ruhig txt wenn es schneller ist.

Alleine der Unterschied zwischen einem Feld VarChar(90) und TiniText (auch nur 90 Zeichen benutzt) beide mit Index belegt, haben einen mittleren Performance-Unterschied von Faktor 77 gebracht. Also VarChar war schneller.

so einen Unterschied hätte ich jetzt nicht erwartet, aber das liegt vermutlich vor allem am Index. Für die problematik hier würde ich  bloß keinen index verwenden, der verlangsamt die Inserts nur für nichst und wieder nichts. Den Index kann man ggfs. danach erzeugen.

Folgende Punkte würe ich bei einer MySQL-Lösung raten:

• http://de.mysql.com/documentation/mysql/bychapter/manual.de_MySQL_Optimisation.html#Insert_speed und alles drum herum lesen ;-)
• verwende INSERT DELAYED
• verwende _nur_ Spalten mit fester Länge -> CHAR
• verwende wenn möglich mysql_pconnect()
• verwende _keinen_ Index über die Tabelle
• wenn Du kannst vergrößere einige passende MySQL-Parameter

Mehr fällt mir dazu jetzt nicht ein.

Aber ich bleibe dabei das ich glaube das TXT-Files schneller sind ;-) Ich werde es bei Gelegenheit mal selber testen. Ich weiß jedenfalls das ich bei irgendeienm alten Versuch mal knapp 40 Schreibzugriffe/Sekunde auf eine Datei geschafft habe(ebenfalls von verschiedenen Rechnern aus, mit forken...), und das war ein Shared-Hoszting Rechner, also ich war nicht der einzige Kunde auf dem Rechner, und meine Scriptlaufzeiten und Performance wurde künstlich begrenzt, geschreiben hat ein PERL-Script. Helfen könnte sicherlich noch ein C-Script oder PHP als Apache-Modul, oder noch besser PERL als Apache-Modul.

Viele Grüße
Andreas

[web_dacor]

Hallo Andreas, Thomas und Michael

den MySQL-Artikel kannte ich schon, er gibt aber eben nur
Anhaltspunkte.

Deshalb moechte ich Thomas wirklich fuer seinen Erfahrungs-
bericht danken!

Sicher gibt es fuer ein Problem immer viele Loesungen und oft
it nicht die gleiche fuerr das naechste Problem das Beste.

Ich hatte mir unter PHP3 mal die Muehe gemacht MySQL mit ner
Textfile-Loesung zu vergleichen:
Neben der wichtigen Anzahl der zu
erwartenden Zugriffe ist natuerlich auch immer das
zur Verfuegung stehende System wichtig:
Es machte damals einen Unterschied von Faktor 5
(bei ca 10 Zugriffen pro Sekunde),
ob die MySQL persistent (eben mit mysql_pconnect) auf dem
localhost betrieben werden kann (wie haeufig Stand alone Server),
oder auf einem eigenen Datenbank-Server liegt
(wie haeufig im shared hosting).
Deshalb siegte damals die Textfile-Loesung, da MySQL
in der ersten Variante fuer das Webprojekt
nicht zur Verfuegung stand.

Das wuerde ich heute nicht wieder machen

• vor allem weil mir das Handling nciht zusagt...

Gruesse Dacor