nicht angemeldet
Serverlast absch㤴en - aber wie?
Moin moin,
ich stehe vor einem kleinen Problem: Ich muss abschätzen, ob ein Server für den zu erwartenden Traffic auf einer bestimmten Website ausreicht oder nicht.
Es geht dabei um einen teils statischen, teils dynamischen Auftritt (PHP/MySQL).
Keine Sorge, ich erwarte hier keine komplette Erklärung, dazu ist das Thema wohl zu komplex. Mich würde vielmehr interessieren, ob jemand Informationsquellen zum Thema kennt (Onlinetutorials, Bücher, etc.)
Vielen Dank im voraus
Henk
-
Huhu Henk
ein Buch kenne ich immerhin zum Teil (habe es noch nicht ganz durch)
http://www.oreilly.de/catalog/webpt2/
ob das besonders gut ist kann ich nicht beurteilen, dazu stecke ich zu wenig in dieser Materie drin, ich fand es aber recht interessant und gut geschrieben.
Schau es Dir halt mal an.
so short
Viele Grüße
lulu
-
Hallo Henk,
wenn Du Einschätzungen für eigene Server machen musst, dann hast Du sicherlich eine Standleitung ins Internet. Wie leistungsstark ist die? Der Flaschenhals könnte in der Anbindung sitzen.
Ressourcenfressend sind immer die Plattenzugriffe.
Ich arbeite z.B. mit Hilfe eines PHP-Scriptes eine Log-Datei durch, die schon mal 2.000.000 Zeilen und 60MByte haben kann. Das dauert dann so ca. 90 bis 100 Sekunden. Der server ist aber trotzdem noch sehr gut in der Lage, nebenbei z.B. mein Testscript http://bitworks.de/test/endlos.php mehrfach zu bedienen. Da fängt der erst richtig an zu strahlen.
Resumeé:
--------
Ein Raid muss her, am Bessten gleich ein redundantes, dann entfällt in Zukunft die lästige Datensicherung mit Streamer.Die Medienantwortzeiten beeinflussen extrem die Performance.
Außerdem solltest Du heutzutage schon 1Gig schnellen Speicher im System haben, dann reicht sogar ein Athlon 700 noch für viele viele Zugriffe.Ich hoffe, meine paar Erfahrungswerte helfen Dir auch ein Bisschen weiter.
Liebe Grüße aus http://www.braunschweig.de
Tom
-
Hallo Tom,
vielen Dank auch an lulu.
Zusammen mit den Einschätzungen einiger anderer Leute denke ich nun, das unser Server das ohne Probleme schafft. Vor allem auch, weil ich (durch Verwendung von Javascript) es schaffen werde, ca. 95% des Auftrittes statisch zu machen.
Gruß Henk
-
Hi Henk,
falls Du nochmal schaust:
Es ist auch möglich, Seiten auf Vorrart zu berechnen. Das heißt, nicht bei jedem Aufruf des Scriptes tatsächlich in die DB zu steigen und alle komplizierten Abfragen zu machen, wenn sich eh nur zweimal am Tag was ändert. Dann kann man ja irgendwo ein Änderungsflag in der DB hinterlegen, und die neu berechnete Seite irgendwo als HTML speichern. Wenn jetzt der nächste Besucher die gleiche Anfrage stellt, wird nicht das ganze Konstrukt aus der Datenbank neu erzeugt, sondern nur die noch gültige letzte Seite ausgegeben.
Je nach Aufgabenstellung kann man da bis zu 90% Serverlast einsparen.
Grüße
Tom
-
Moin Tom,
Es ist auch möglich, Seiten auf Vorrart zu berechnen.
das würde man dann ja wohl "caching" nennen, oder?
In meiner Datenbank ändert sich zwar selten etwas, dafür gibt es eine Suchfunktion, die mehrere Argumente zulässt, so das die SQL-Statements und somit auch die Ergebnisseiten wohl nur selten gleich aussehen werden.
Für andere Szenarien könnte ich mir das aber sehr gut vorstellen.
Danke!
Henk
-
-
-
-
Hi Henk,
Es geht dabei um einen teils statischen, teils
dynamischen Auftritt (PHP/MySQL).gefühlsmäßig würde ich sagen: Bei den Datenbankzugriffen hast Du die besten Chancen, Performance kaputt zu machen.
Insofern würde ich mir das Tuning der SQL-Zugriffe und -Tabellen ganz oben auf die Agenda schreiben - auch dann, wenn es nur 5% aller Zugriffe sein sollten.
(Schau Dir das Self-Portal an - da macht die Archivsuche _viel_ weniger als 5% der Zugriffe aus ...)Viele Grüße
Michael-
Hallo!
(Schau Dir das Self-Portal an - da macht die Archivsuche _viel_ weniger als 5% der Zugriffe aus ...)
Moment! Zugriff ist aber wohl nicht gleich Zugriff. Meines Wissens kostet es um den Faktor 10 mal mehr Perform,ance, wenn Du statt einer html-Datei eine php-Datei auslieferst, bzw. vorhher parst. Und wenn dann noch db-Zugriffe dazu kommen wird das ganze nochmal schlimmer!
Wenn ich mal schätzen darf kostet ein Zugriff auf die Suche standardmäßig über die 4 ersten Index-Dateien bestimmt 1.000 - 10.000 mal so viel Performance wie der Zugriff auf eine einfache html-Datei, oder liege ich hier falsch?
Grüße
Andreas-
Hi,
(Schau Dir das Self-Portal an - da macht die
Archivsuche _viel_ weniger als 5% der Zugriffe
aus ...)Wenn ich mal schätzen darf kostet ein Zugriff auf
die Suche standardmäßig über die 4 ersten Index-
Dateien bestimmt 1.000 - 10.000 mal so viel
Performance wie der Zugriff auf eine einfache html-
Datei, oder liege ich hier falsch?eben - genau das meinte ich. Die häufigsten Zugriffe zu tunen ist wichtig - die teuersten aber ebenfalls.
Viele Grüße
Michael-
Hallo!
eben - genau das meinte ich. Die häufigsten Zugriffe zu tunen ist wichtig - die teuersten aber ebenfalls.
zu meiner Schande muß ich gestehen, dass ich das Anfangsposting leider nicht gelesen habe, denn darin steht ja:
ich stehe vor einem kleinen Problem: Ich muss abschätzen, ob ein Server für den zu erwartenden Traffic auf einer bestimmten Website ausreicht oder nicht.
Da steht "TRAFFIC" und nicht "PERFORMANCE". Das ist ein kleiner Unterschied würde ich mal sagen. Aber gerade Traffic sollte er sich doch recht einfach ausrechnen können, er muß halt nur wissen wieviele Besucher, und wie groß die Seiten im Schnitt sind.
Wenn es um Traffic-Ersparnis geht, würde ich 3 Sachen machen:
1. Wo geht gzip-komprimiert ausliefern
2. Wie auch schon geschreiben wurde die Seiten nicht ständig dynamisch erzeugen, aber aus einem anderen Grund: wenn die Seiten statisch sind, können sie gecached werden, von Browser, Proxy...
3. Nicht zwanghaft alles probieren in Javascipt zu schreiben, denn dann muß evtl. deutlich mehr Code in die Seite als bei einer dynamisch erzeugten aber als statisch gespeicherten Seite!Grüße
Andreas-
Hi Andreas,
eben - genau das meinte ich. Die häufigsten
Zugriffe zu tunen ist wichtig - die teuersten
aber ebenfalls.
Da steht "TRAFFIC" und nicht "PERFORMANCE".bei mir steht "teuer" - ohne Angabe der "Währung".
Aber gerade Traffic sollte er sich doch recht
einfach ausrechnen können, er muß halt nur wissen
wieviele Besucher, und wie groß die Seiten im
Schnitt sind.Und wieviele dieser Benutzer ihren Browser so konfiguriert haben, daß er komprimierte Konfiguration unterstützt, und welche Caching-Einstellungen diese Browser haben, und welche Caching Proxies von den Providern bzw. Firmennetzen dieser Besucher verwendet werden, und ... und ... und ...
- Wo geht gzip-komprimiert ausliefern
Full ACK.
- Wie auch schon geschreiben wurde die Seiten nicht
ständig dynamisch erzeugen, aber aus einem anderen
Grund: wenn die Seiten statisch sind, können sie
gecached werden, von Browser, Proxy...
Auch dynamische Seiten können gecached werden! (Der Client hat doch keine Ahnung, ob eine Seite statisch oder dynamisch ist - in den HTTP-Headern steht es nicht drin.) Man muß halt wissen, was man tut ...
- Nicht zwanghaft alles probieren in Javascipt zu
schreiben, denn dann muß evtl. deutlich mehr Code in
die Seite als bei einer dynamisch erzeugten aber
als statisch gespeicherten Seite!
Das macht schon alleine wegen des Aufwandes keiner - wer JavaScript einsetzt, tut es, weil sein Problem mit HTML alleine nicht lösbar ist.
Du wirst vermutlich lachen - aber ich habe (dienstlich) ein Paket von Seiten, das wir zur _Verbesserung_ der Performance clientseitig per JavaScript generieren lassen ... (die Daten gehen als CSV zum Browser, und der malt dann die hübschen Sachen daraus).
Viele Grüße
Michael-
Hi!
eben - genau das meinte ich. Die häufigsten
Zugriffe zu tunen ist wichtig - die teuersten
aber ebenfalls.
Da steht "TRAFFIC" und nicht "PERFORMANCE".bei mir steht "teuer" - ohne Angabe der "Währung".
hast Du etwa auch noch keinen "pro-account"?
;-)Aber gerade Traffic sollte er sich doch recht
einfach ausrechnen können, er muß halt nur wissen
wieviele Besucher, und wie groß die Seiten im
Schnitt sind.Und wieviele dieser Benutzer ihren Browser so konfiguriert haben, daß er komprimierte Konfiguration unterstützt, und welche Caching-Einstellungen diese Browser haben, und welche Caching Proxies von den Providern bzw. Firmennetzen dieser Besucher verwendet werden, und ... und ... und ...
Genau geht das eh nicht, man muß sich halt ein bisschen auskennen indem man seine Logfiles analysiert. Da steh alles was man wissen muß um wenigstens nmal gfrob überschhöagen zu können, genau geht es eh nicht, zumindest kann ich nicht hellsehen!
- Wie auch schon geschreiben wurde die Seiten nicht
ständig dynamisch erzeugen, aber aus einem anderen
Grund: wenn die Seiten statisch sind, können sie
gecached werden, von Browser, Proxy...
Auch dynamische Seiten können gecached werden! (Der Client hat doch keine Ahnung, ob eine Seite statisch oder dynamisch ist - in den HTTP-Headern steht es nicht drin.) Man muß halt wissen, was man tut ...
stimmt!
- Nicht zwanghaft alles probieren in Javascipt zu
schreiben, denn dann muß evtl. deutlich mehr Code in
die Seite als bei einer dynamisch erzeugten aber
als statisch gespeicherten Seite!
Das macht schon alleine wegen des Aufwandes keiner - wer JavaScript einsetzt, tut es, weil sein Problem mit HTML alleine nicht lösbar ist.
Das hört sich aber in dem Posting unten anders an:
<quote: </?m=142066&t=25876>>
[...] Vor allem auch, weil ich (durch Verwendung von Javascript) es schaffen werde, ca. 95% des Auftrittes statisch zu machen.
</quote>Du wirst vermutlich lachen - aber ich habe (dienstlich) ein Paket von Seiten, das wir zur _Verbesserung_ der Performance clientseitig per JavaScript generieren lassen ... (die Daten gehen als CSV zum Browser, und der malt dann die hübschen Sachen daraus).
Ja, das habe ich auch schonmal überlegt. Das was an html, also reinen "client-server - Seiten" wirklich nervig ist, ist die Wartezeit! Auch wenn alles statisch ist dauert es meist ein oder zwei Sekunden, bis was passiert, bzw. bis die Seite volständig geladen, ist, vor alem wenn man keine Frames verwendet. Mit Frames und Javascript läßt sich eine Anwendung richtig schön "flüssig" gestalten, ich überlege das in naher Zukunft mal für ein Intranet einzusetzen, aber ich bin kein Javascript-Experte, aber wenn ich es so wenig verwende werde ich nie einer ;-)
Grüße
Andreas-
Hallo Nachtschwärmer ... ;-)
Da steht "TRAFFIC" und nicht "PERFORMANCE".
Ich hab mich vielleicht nicht ganz klar ausgedrückt. Die Bandbreite wird wohl nicht das Problem sein, ich hatte bloss Schiss, das der Server Rechenleistungsmässig in die Knie geht.
Gibt es hier eigentlich auch jemanden, der so etwas schon mal wirklich berechnet hat, und nicht so "pi mal Daumen" abgeschätzt?
Du wirst vermutlich lachen - aber ich habe (dienstlich) ein Paket von Seiten, das wir zur _Verbesserung_ der Performance clientseitig per JavaScript generieren lassen ... (die Daten gehen als CSV zum Browser, und der malt dann die hübschen Sachen daraus).
Hübsche Idee, werde ich mir merken...
In meinem Fall lasse ich allerdings nicht komplette Inhalte per JS generieren, sondern lediglich die Einbindung für das Menu, das je nach übergebenem Variablenwert als Flash- oder HTML-Version geladen wird.
Bisher lag die Seite auf einem Server, auf dem auch ".html"-Dateien geparst wurden, da konnte man das ohne Probleme in PHP machen, aber jetzt...
Gruß Henk
-
Hi Henk,
Die Bandbreite wird wohl nicht das Problem sein,
ich hatte bloss Schiss, das der Server
Rechenleistungsmässig in die Knie geht.eben - so hatte ich das Ausgangsposting auch in Erinnerung.
Und deshalb 'greift' die Suchmaschine als Beispiel.Gibt es hier eigentlich auch jemanden, der so etwas
schon mal wirklich berechnet hat, und nicht so "pi
mal Daumen" abgeschätzt?Das Problem ist, daß man für das Rechnen wirklich zu viele Parameter bräuchte, die man nicht hat (siehe mein vorheriges Posting). Du kannst die ankommenden Zugriffe nicht mal vage schätzen - wenn plötzlich alle Benutzer des WWW Dein Angebot gut finden, dann bricht Dein Server definitiv zusammen.
Bei einem Dienst mit Zugangskontrolle sieht die Sache natürlich anders aus. Auf unserer Serverfarm arbeiten nur Kunden mit registrierter Benutzerkennung (und pro Benutzerkennung nur einer gleichzeitig, via cookie-basiertem Session-Konzept) - da habe ich die Kontrolle, wie viele Benutzerkennungen pro Maschine ich frei schalten lasse (im Zweifelsfalle schieben wir eben einen Virtual Host auf die Maschine nebenan und ändern im Proxy-Server davor eine IP-Adresse).
Natürlich kannst (und sollst!) Du Deine Logfiles lesen und nachbalancieren, wo möglich. Es hilft auch, sich vorher ein Maßnahmenpaket zu schnüren, wie Du das ganz richtig tust.
Aber es reicht in der Tat eine einzige ressourcenhungrige bzw. schlecht getunete Anwendung, um den gesamten Server in den Abgrund zu reißen.
Und deshalb halte ich eine Schwachstellenanalyse für wichtiger als eine allgemeine Traffic-Abschätzung - denn für die Auslieferung von statischen Seiten sind die gängigen Rechner allemal ausreichend, wie Du am Self-Portal mit seinem gigantischen Traffic ja leicht erkennen kannst.
Gerade _weil_ zwischen der Auslieferung einer statischen und einer dynamischen Seite mehrere Zehnerpotenzen an CPU-Aufwand liegen können, lohnt es sich, gezielt die teuersten Zugriffe zu optimieren.ich habe (dienstlich) ein Paket von Seiten,
das wir zur _Verbesserung_ der Performance
clientseitig per JavaScript generieren lassen
... (die Daten gehen als CSV zum Browser, und
der malt dann die hübschen Sachen daraus).
Hübsche Idee, werde ich mir merken...Das hat allerdings massive Randbedingungen zu beachten.
Beispielsweise: Wenn als Ergebnis nicht das gesamte Dokument neu gemalt werden soll, aber ein neuer HTTP-Zugriff erforderlich ist, wohin mit den Daten?
Wir arbeiten mit Framesets - da fällt ein unsichtbarer Hintergrund-Frame, in dem man die Daten "zwischenlagern" kann, so nebenbei mit ab ...Bisher lag die Seite auf einem Server, auf dem auch
".html"-Dateien geparst wurden, da konnte man das
ohne Probleme in PHP machen, aber jetzt...... äh, ja? Was hindert Dich daran, Deinen aktuellen Server so zu konfigurieren, daß er Deinen Anforderungen entspricht?
Eine solche Grundvoraussetzung solltest Du nicht durch workarounds zu kompensieren versuchen - das lohnt sich nicht. Lieber gleich eine Konfiguration (ggf. bei einem tauglichen Provider), die für Deinen Einsatzfall ausreicht.
Viele Grüße
Michael-
Hallo Michael,
Bisher lag die Seite auf einem Server, auf dem auch
".html"-Dateien geparst wurden, da konnte man das
ohne Probleme in PHP machen, aber jetzt...... Ãh, ja? Was hindert Dich daran, Deinen aktuellen Server so zu konfigurieren, daà er Deinen Anforderungen entspricht?
Nichts. Ich halte nur nichts davon, statische seiten durch einen PHP-Interpreter zu jagen. Bisher konnte ich das nicht Ãndern, da der Server sozusagen bei einem Provider stand. Jetzt wollen wir die Sache selber hosten, nur wird uns der Provider wohl kaum erzÃhlen, auf was fÃr einer Maschine die Sache lÃuft, usw.
Nur die Zahl der Page Impressions habe ich.
Auf die Idee mit JS statt PHP bin ich nur aus PerformancegrÃnden gekommen, nicht wegen der HTML-Parserei...
Gruà Henk
und vielen Dank!
-
-
Hallo,
bisschen spät, dass ich das hier noch lese, aber vielleicht schaut ja Michael trotzdem nochmal rein...
Gibt es hier eigentlich auch jemanden, der so etwas schon mal wirklich berechnet hat, und nicht so "pi mal Daumen" abgeschätzt?
Das dürfte wohl ne längere Dokrorarbeit werden, das berechenbar zu machen. Du müsstest das ja bis auf die Assemblerebene und die Hardware-Parameter (Zugriffszeit) runterbrechen. Eine gute Schätzug ist besser als eine schlechte Rechnung ;-)
Du wirst vermutlich lachen - aber ich habe (dienstlich) ein Paket von Seiten, das wir zur _Verbesserung_ der Performance clientseitig per JavaScript generieren lassen ... (die Daten gehen als CSV zum Browser, und der malt dann die hübschen Sachen daraus).
Wie geht das, dass der Browser nicht sagt: "Download des files?"
Gruß
Tom
-
- Wie auch schon geschreiben wurde die Seiten nicht
-
-
-
-