nicht angemeldet
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