das forum ist manchmal echt extrem langsam.

folgende vorschläge würden den umfang eures datentraffics um einiges reduzieren:

- benachrichtigunsmail-texte kürzen, am besten nur die beiden links und nur ein stichwort dazu z.b. von diesem thema abmelden
- die ordnernamen graphics und slices auf g und s ändern
- aufrufe wie <td nowrap="nowrap" valign="middle" align="left" style="white-space: nowrap;"> in ein stylesheet auslagern.

das alles zusammen sollte mal einige bytes (eher kilobytes) pro seitenaufruf sparen.

Hallo!

Die Geschwindigkeit des Servers hängt praktisch nicht von der übertragenden Datenmenge ab. Außerdem halte ich die Performance des Servers für sehr gut.

Eine Maßnahme wie das Kürzen der Mail geht zu Lasten der Usability, die Ordnernamen sollten auch so bleiben, wie sie sind. Du hast bei Dir auf dem Rechner sicherlich auch gerne Ordnernamen, von denen Du weißt, was sie bedeuten.

MfG
Christian

Christian S. hat folgendes geschrieben:

Die Geschwindigkeit des Servers hängt praktisch nicht von der übertragenden Datenmenge ab. Außerdem halte ich die Performance des Servers für sehr gut.

naja du hängst wahrscheinlich auch per LAN dran. weniger strings durchzuackern bedeutet aber nicht nur eine entlastung des netzwerks sondern auch des prozessors

Zitat:

Eine Maßnahme wie das Kürzen der Mail geht zu Lasten der Usability

sehe ich ein...

Zitat:

die Ordnernamen sollten auch so bleiben, wie sie sind. Du hast bei Dir auf dem Rechner sicherlich auch gerne Ordnernamen, von denen Du weißt, was sie bedeuten.

schon, aber wenn deren dateinamen in jeder html-seite 50 mal vorkommen macht das schon mal fast ein kilobyte.

ich habe mir erlaubt mal schnell per search & replace die 4 häufigsten ordnernamen in jeweils einen buchstaben zu ändern
und die ersten 20 öfter auftretenden styles mit einem class tag zu ersetzen. resultat : die html-seite von "kleines rätsel " hat nun 92 kb statt 98.
ohne auf irgendwas verzichten zu müssen. käme auch den modem-benutzern zugute....

retnyg hat folgendes geschrieben:

Christian S. hat folgendes geschrieben: Die Geschwindigkeit des Servers hängt praktisch nicht von der übertragenden Datenmenge ab. Außerdem halte ich die Performance des Servers für sehr gut. naja du hängst wahrscheinlich auch per LAN dran.

Nein. Und die Performance des Servers ist auch unabhängig davon, mit welcher Leitung ich dran hänge

retnyg hat folgendes geschrieben:

weniger strings durchzuackern bedeutet aber nicht nur eine entlastung des netzwerks sondern auch des prozessors

Das dürfte unterhalb der Messgenauigkeit liegen.

retnyg hat folgendes geschrieben:

Zitat: die Ordnernamen sollten auch so bleiben, wie sie sind. Du hast bei Dir auf dem Rechner sicherlich auch gerne Ordnernamen, von denen Du weißt, was sie bedeuten. schon, aber wenn deren dateinamen in jeder html-seite 50 mal vorkommen macht das schon mal fast ein kilobyte.

Das mag sein. Aber ich möchte, dass die Pfade lesbar bleiben. Ich habe keine Lust, einen Fehler zu suchen und nach zehn Minuten zu merken, dass dort, wo ein "g" steht eigentlich ein "s" stehen muss. Die Ordnernamen werden wir daher nicht ändern.

Wir schauen auch immer, dass wir CSS-Classes benutzen, unsere CSS-Files nehmen insgesamt schon 15KB ein. Irgendwann werde ich da nochmal durchgehen, steht aber im Moment nicht oben auf meiner To-Do-Liste.

naja die vorgeschlagenen änderungen würden immerhin 5% weniger traffic bedeuten - für beide seiten
wenn man noch die dateinamen drastisch kürzen würde wären sicher fast 10% drin....

imho nicht unbeträchtlich, im gegensatz zur grösse des css files da dieses vom browser gecached wird.

ich finde das laden der seite garnicht mal so schlimm...aber es kommt manchmal zeiten, da dauert es ca 3-5 sekunden bis sich überhaupt was tut mit dem server...

Kidix hat folgendes geschrieben:

ich finde das laden der seite garnicht mal so schlimm...aber es kommt manchmal zeiten, da dauert es ca 3-5 sekunden bis sich überhaupt was tut mit dem server...

Das ist richtig, da hatten wir vor ein paar Wochen mal einige Probleme mit. Da mussten wir den Server neu starten, dann ging es wieder. Im Moment stelle ich das aber nicht fest.

Christian S. hat folgendes geschrieben:

Kidix hat folgendes geschrieben: ich finde das laden der seite garnicht mal so schlimm...aber es kommt manchmal zeiten, da dauert es ca 3-5 sekunden bis sich überhaupt was tut mit dem server... Das ist richtig, da hatten wir vor ein paar Wochen mal einige Probleme mit. Da mussten wir den Server neu starten, dann ging es wieder. Im Moment stelle ich das aber nicht fest.

genau das ist es was ich derzeit feststelle, drum auch die vorschläge. wenn ich kurz nach betätigen eines links einen anderen anklicke warte ich z.t. über 10 sekunden bis mal daten daherkommen

retnyg hat folgendes geschrieben:

genau das ist es was ich derzeit feststelle, drum auch die vorschläge. wenn ich kurz nach betätigen eines links einen anderen anklicke warte ich z.t. über 10 sekunden bis mal daten daherkommen

das hat dann definitiv nichts mit der Datenmenge zu tun.

Ich tippe mal, dass dieser Fehler irgendwo anders liegt, denn wenn es an uns läge, stände in der SB schon mindestens fünfmal "Ist das Forum bei Euch auch so lahm?"

Christian S. hat folgendes geschrieben:

das hat dann definitiv nichts mit der Datenmenge zu tun.

ich dachte mir dass die leitung aufgrund hohen traffics ausgelastet ist...und deshalb meine anfragen so lange gereiht werden.

Wenn ich das richtig sehe steht der Server in einem Schlund-Rechenzentrum. Und sollte es das DF da wirklich schaffen, die Leitung dicht zu machen (18 Gigabit über 5 Netzbetreiber!!!), dann ist die einzeige Alternative, die Mühle direkt ans deCIX zu stellen *sfg*

Ausserdem denke ich (auch als Serverbetreiber *g*) dass eine Änderung der Vereichnisnamen einen Geschwindigkeitsvorteil bringt, der definitiv nicht messbar ist. Dafür hat sowohl TCP/IP als auch die eigentlichen HTML-Files einen zu großen Overhead, dass sich das im Bereich < 0,5% bewegen dürfte.

Viele Grüße,

Matthias

neojones hat folgendes geschrieben:

Wenn ich das richtig sehe steht der Server in einem Schlund-Rechenzentrum. Und sollte es das DF da wirklich schaffen, die Leitung dicht zu machen (18 Gigabit über 5 Netzbetreiber!!!), dann ist die einzeige Alternative, die Mühle direkt ans deCIX zu stellen *sfg* Ausserdem denke ich (auch als Serverbetreiber *g*) dass eine Änderung der Vereichnisnamen einen Geschwindigkeitsvorteil bringt, der definitiv nicht messbar ist. Dafür hat sowohl TCP/IP als auch die eigentlichen HTML-Files einen zu großen Overhead, dass sich das im Bereich < 0,5% bewegen dürfte. Viele Grüße, Matthias

wenn du aufgepasst hättest hättest du gesehen dass ich ne html-seite vom DF mit ein wenig search&replace von 98 auf 92 kb getunet habe (in 5 min, wäre sicher noch mehr drin gewesen). das sind über 5 % der HTML seite
wenn ich bei jeder html-seite 5 % spare ist das deutlich mehr als "< 0,5%"

Na da hast Du natürlich recht.
5% sind trotzdem nicht spürbar.

retnyg hat folgendes geschrieben:

neojones hat folgendes geschrieben: Wenn ich das richtig sehe steht der Server in einem Schlund-Rechenzentrum. Und sollte es das DF da wirklich schaffen, die Leitung dicht zu machen (18 Gigabit über 5 Netzbetreiber!!!), dann ist die einzeige Alternative, die Mühle direkt ans deCIX zu stellen *sfg* Ausserdem denke ich (auch als Serverbetreiber *g*) dass eine Änderung der Vereichnisnamen einen Geschwindigkeitsvorteil bringt, der definitiv nicht messbar ist. Dafür hat sowohl TCP/IP als auch die eigentlichen HTML-Files einen zu großen Overhead, dass sich das im Bereich < 0,5% bewegen dürfte. Viele Grüße, Matthias wenn du aufgepasst hättest hättest du gesehen dass ich ne html-seite vom DF mit ein wenig search&replace von 98 auf 96 kb getunet habe (in 5 min, wäre sicher noch mehr drin gewesen). das sind über 5 % der HTML seite wenn ich bei jeder html-seite 5 % spare ist das deutlich mehr als "< 0,5%"

Bei mir ist 96/98*100% = 98%, du sparst also 2%

AXMD

AXMD hat folgendes geschrieben:

retnyg hat folgendes geschrieben: neojones hat folgendes geschrieben: Wenn ich das richtig sehe steht der Server in einem Schlund-Rechenzentrum. Und sollte es das DF da wirklich schaffen, die Leitung dicht zu machen (18 Gigabit über 5 Netzbetreiber!!!), dann ist die einzeige Alternative, die Mühle direkt ans deCIX zu stellen *sfg* Ausserdem denke ich (auch als Serverbetreiber *g*) dass eine Änderung der Vereichnisnamen einen Geschwindigkeitsvorteil bringt, der definitiv nicht messbar ist. Dafür hat sowohl TCP/IP als auch die eigentlichen HTML-Files einen zu großen Overhead, dass sich das im Bereich < 0,5% bewegen dürfte. Viele Grüße, Matthias wenn du aufgepasst hättest hättest du gesehen dass ich ne html-seite vom DF mit ein wenig search&replace von 98 auf 96 kb getunet habe (in 5 min, wäre sicher noch mehr drin gewesen). das sind über 5 % der HTML seite wenn ich bei jeder html-seite 5 % spare ist das deutlich mehr als "< 0,5%" Bei mir ist 96/98*100% = 98%, du sparst also 2% AXMD

tippfehler, es sind 92 KB (siehe beitrag nummer 3)

Auch die Aktivierung der GZIP-Komprimierung für das Forum sollte noch einiges an Geschwindigkeit bei der Übertragung, vor allem bei langsamen Verbindungen, bringen, auch wenn damit eine geringfügig höhere Auslastung des Servers zwecks Datenkomprimierung verbunden ist.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Auch die Aktivierung der GZIP-Komprimierung für das Forum sollte noch einiges an Geschwindigkeit bei der Übertragung, vor allem bei langsamen Verbindungen, bringen, auch wenn damit eine geringfügig höhere Auslastung des Servers zwecks Datenkomprimierung verbunden ist.

Das haben wir vor einiger Zeit mal überlegt, da jedoch viele Probleme im Zusammenhang damit berichtet werden und es auch sein kann, dass ein Browser diese Komprimierung nicht beherrscht, haben wir uns für "Never touch a running system" entschieden.

Ich werde irgendwann nochmal danach schauen, was man mittels Klassen machen kann, aber das wird erst nach dem (bald) kommenden Update etwas.

wieso muss der browser denn diese komprimierung beherrschen?`das wird doch nur serverseitig komprimiert und dekomprimiert! oder?

Es geht um den Übertragungsweg vom Server zum Client.
Wenn der Server intern komprimiert um dann selbst wieder zu dekomprimieren könnte man sichs ja auch sparen, oder?

Viele Grüße,

Matthias

Die Komprimierung über die PHP-Schnittstelle der Output-Handler ist Header-Basiert implementiert, d.h. die Handler komprimieren nur, wenn der anfragende Browser auch angibt, dass er diese beherrscht. Bei HTML ergibt dies oft Komprimierungsraten von 50%++.

Bei Fehlern im Browser (recht selten), kann es aber zu witzigem Zeichensalat auf dem Bildschirm kommen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.