Fotogalerien in neuer Forumsversion möglich?

[Red]

...Und DSL geht bei mir sowieso nicht (Glasfaserkabel)

Noch einer mit dem Problem. *g*

[colophonius]

Wie hast du´s gelöst?
N Kumpel macht Sky-DSL, aber das kostet

[Red]

Wie hast du´s gelöst?

Garnicht, hab nur ISDN.

[rembox]

lol sky dsl is da letze schaiiiz sag ich dia! da spar lieber das Geld und geh mit isdn ins www

tchjoo red ^^ mein beileid aber irgendwann wird die zeit kommen...deine zeit für dsl

[el panecillo]

wenn ma unkomprimierte dateien (zb .bmp) per 56k übertragt gehn sogar 16kbyte/sek

[salsa]

mmmhm wieso sollten .bmp dateien schneller gehen, als andere?

Zum allgemeinen verständnis, wen es interessiert:

natürlich kann man mit einem 56kbit Modem nicht wirklich 56kbit (7kB/s) herunterladen.
Weil: einen gewissen Teil der Bandbreite das TCP/IP Protokoll verschlingt(nennt man "overhead"), und der Durchsatz auch noch von der MTU (Maximum Transfer Unit) abhängt.

Theorethisch ist etwa 50 kbit/s verwendbar also etwas mehr als 6kB/s
Man könnte den Durchsatz noch verbessern, wenn man die MTU anpasst(kann man konfigurieren).

Wen es noch genauer interessiert:
http://www.faqs.org/rfcs/rfc1144.html

[noox]

Bei Modems wird oft eine Komprimierung bei der Übertragung eingesetzt. Eine .jpg oder .gif, .mpg, .mp3-Datei etc. ist schon extrem komprimiert, da holt man nix mehr raus. Aber z.B. bei einer normalen HTML-Seite oder ein .bmp Bild lässt sich noch viel komprimieren.

Bei uns am Forum werden übrigens schon vom Webserver (eigentlich von PHP) die Seiten komprimiert. Damit werden die HTML-Seiten um 80 - 90% schneller, werden allso 5 - 10 mal schneller übertragen. Da kann dann das Modem auch nix mehr komprimieren.

[salsa]

ah...mod_gzip?

hab ich vergessen. danke der antwort...
allerdings wird das nicht von allen clients unterstützt, und muss erst zwischen client und server ausgehandelt werden. der geschwindigkeitsvorteil haängt von der rechenleistung von server und client ab (zugegebenermassen mittlerweile immer weniger relevant bei den clients. Die Serverleistung wird jedoch beträchtlich beansprucht)

ansonsten würde ich sagen trägt die kompression ja nicht zur übertragungsgeschwindigkeit bei. (das ist natürlich ansichtssache)
denn messbar wird ja trotzdem nicht mehr als 50kbit oder so übertragen...


P.S.: wenn du mod_gzip meinst, dann mancht das komprimieren/dekomprimieren doch nicht das PHP sondern das Apache Modul.

P.P.S.:
Bei genauerer Betrachtung muss ich mir eingestehen, dass ich etwas voreilig war...
du verwendest wharscheinlich den outputbuffer von php, der gzip komprimiert ist("ob_gzhandler").(hätt ich mir gleich denken können d'oh)
oder doch "zlib.output_compression"?

[noox]

ja, ich verwende das von PHP. mod_gzip und mod_php arbeiten nicht zusammen beim Apache 1.3.x.

Kenn keinen Browser mehr, den du gerne verwenden würdest, der Compression nicht kann. Und wenn er sie nicht kann, dann wird eh nicht komprimiert. Sprich der Server schaut ja, ob der Client ihm beim Accept-Encoding "gzip" mitschickt.

eigentlich hat mir noch niemand wirklich sagen können, wieviel die gzip-compression wirklich kostet. Mir ist bei meinen Server noch nicht aufgefallen, dass sie etwas merklich kostet. Vielleicht mess ich's mal raus.

Bei mir liegts vermultich auch daran, dass - so vermute ich zumindest - bei meinem Server das I/O (sprich die Platte) zu langsam ist. Wenn er stärker belastet ist - also einige Jobs in der Warteschlange hängen, dann ist der Prozesser meist trotzdem kaum ausgelastet und der RAM (1GB) nur zu 1/4 bis zur Hälfte benutzt. Der Rest für Caches und Buffer. Zum Zippen wird aber nur die CPU und ein bisschen RAM verwendet.

Einen Vorteil hat nämlich die Compression: Die Prozesse des Webservers, die die Seiten an die Clients ausliefern nicht so lange blockieren. Beispiel: Eine Seite braucht zum Übertragen 10 Sekunden. Komprimiert ist sie allerdings in unter 2 Sekunden komplett beim Client. Er kann viel schneller den nächste bedienen.

[salsa]

auch bei php gibt es 2 versionen (wie oben geschrieben.) verwendest du den outputbuffer?

Klar dass keiner genau sagen kann, wieviel prozessor leistung das gzippen verbraucht...das ist ja abhängig von dem, was du komprimierst

aber, wenn eh dsa bottleneck die Platte ist. dann brauchst dir eh keine sorgen machen.

andererseits ist der server dann EXTREM ineffizient! denn du hast 700MB zu viel RAM, und zu viel Prozessorleistung

hast du das mit den 10 respektive 2 sekunden getestet? klingt sehr beachtlich!
Du könntest die "MaxClients" directive verwenden um von deinem httpd noch mehr child-processes zu bekommen, um mehr User gleichzeitig bedienen zu können. Das würde mehr RAM ausnutzen(aber vermutlich auch die Platte etwas mehr beanspruchen )


Ach ja:
Der Server lauft hoffentlich auf Linux/Unix?

[noox]

hauptsächlich ist's abhängig davon wieviel du komprimierst - und mit welchem Algorithmus.

extrem ineffizient halte ich ihn net. momentan zahl ich keine 110 Euro pro Monat für 500 GB IN, 500 GB OUT Traffic, 2,4 GHZ, 2x80 GB Platten, 15 IP-Adressen, Serververwaltungssoftware, Remote-Reboot, etc.

Für SCSI hätte ich schon einiges mehr hinlegen müssen. Und wenn er täglich mehrere GB Daten für's Backupen zippt, dann ist der Prozessor eh ausgelastet.

Und den Speicher kann er wunderbar für diverse Caches verwenden (was er auch macht).


wegen den 10 auf 2 sekunden. Grad beim Forum ist des a Wahnsinn. Die Bilder sind sowieso alle im Cache, weil sie ja ständig die gleichen sind. Aber der HTML-Code kann bis zu 90% komprimiert werden:

http://www.pipeboost.com/GetReport.asp?U...1%26vc%3D1

=> Seite aus dem Forum: 87% komprimiert. Und ich sag mal frech: Wenn's fast 10 mal kleiner ist, dann wird's sicher 5 mal schneller ankommen... Je langsamer die Verbindung, destom mehr wird man's merken.

Bei anderen Seiten sind's oft viel weniger. Aber grundsätzlich ist es schon beachtlich.

Server ist natürlich Linux.