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