Steffen Dettmer schrieb in 2,6K (78 Zeilen):
Bei SSL und CGI funktioniert Cacheing ja nu nicht, also etwas langsamer.
Unsinn. Caching funktioniert schon bei CGI, es sei denn, im Header steht ein entsprechender Hinweis an die Caches. Und die Caches koennen sich dann aussuchen, wie sie die Haltbarkeit selber regeln wollen. :-) Und bei SSL kannst du auch cachen. Ob das gut ist? Andere Frage.
Virenscanner bremsen schon richtig, klar. Aber eine lahme Leitung wird zumindestens nicht viel langsamer, schnelle jedoch IMHO schon. (Reden wir eigentlich über Proxies für zu Hause oder für "richtige" Netze?)
Reden wir jetzt ueber Bandwith oder Latency? *Du* redest ueber Latency, aber du sagst es so, als waere es Bandbreite. Das ist wie ein Politiker vor der Wahl. :-/ Schliesslich wird pro $Zeiteinheit (bei vernuenftigem Ausbau der Caches) genausoviel an Bytes ruebergeschoben. Nur dauert es beim einzelnen Luser halt 0.1-0.2 sec pro Verbindung mehr bei non-cached (und 5 sec weniger bei hits).
AFIAK bezahlte ne Uni den Traffic zum/vom DFN.
Unter Anderem. Der DFN muss ja selber auch zahlen. (Ist ja ein Verein, um die Forschungsinstitute (also gerade auch Unis) zu verbinden.) Das wird dann selbst im einfachsten Fall volumenmaessig auf die Teilnehmer umgelegt. Wenn also (fast) alle weniger teuere USA-Verbindungen machen und dafuer mehr billigere inner-DFN-Verbindungen macht, sinken die Gesamtkosten des DFN, und damit auch die Kosten pro Byte.
Egal, ob der zum Cache geht oder nicht.
Preise werden erst am Ende des Jahres festgelegt.
rumlag ;) Und wie Du schon sagtest, haben die Peerhits einen relativ kleinen Anteil.
50TDM/Jahr ist nicht zu verachten.
Bezahlt ne Uni so aber trozdem!
Jain. IIRC wird nicht nur rein nach Volumen gerechtet, sondern auch wohin geroutet wird. Da sind's dann halt 30TDM statt 70TDM. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com