Entwickler-Ecke

Wünsche, Anregungen & Kritik - Performance DF


retnyg - Di 01.03.05 23:41
Titel: Performance DF
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.


Christian S. - Mi 02.03.05 00:12

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


retnyg - Mi 02.03.05 00:36

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....


Christian S. - Mi 02.03.05 00:42

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.


retnyg - Mi 02.03.05 00:51

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.


Delete - Mi 02.03.05 02:02

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...


Christian S. - Mi 02.03.05 02:07

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.


retnyg - Mi 02.03.05 02:34

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 :?


Christian S. - Mi 02.03.05 03:06

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?" :D


retnyg - Mi 02.03.05 03:13

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.


neojones - Mi 02.03.05 11:34

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


retnyg - Mi 02.03.05 11:44

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%"


neojones - Mi 02.03.05 11:45

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


AXMD - Mi 02.03.05 11:45

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%"


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

AXMD


retnyg - Mi 02.03.05 11:47

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%"


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

AXMD

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


BenBE - Mi 02.03.05 13:15

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.


Christian S. - Mi 02.03.05 13:21

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.


Delete - Mi 02.03.05 14:01

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


neojones - Mi 02.03.05 14:50

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


BenBE - Mi 02.03.05 15:56

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.


Delete - Mi 02.03.05 16:20

Also um auch mal meinen Senf zum Sinn dieses Aufwandes dazuzugeben:
Das Laden der Hauptseite dauert bei mir 2,5 Sekunden (Rush Hours ausgenommen). Wenn man jetzt 5% Traffic spart, bringt das vielleicht einen Zeitvorteil von nur noch 3%, denn DB-Zugriffe etc. müssen ja trotzdem gemacht werden.
Ich hätte einen Zeitvorteil von 2,5s/100*3 = 0,075s. Wow!
Selbst wenn man man ein paar Zugriffe zusammen addiert, kommt man immer noch nicht auf einen nennenswerten Vorteil. Also wenn Performance verbessern, dann bitte andere Ansatzpunkte!


F34r0fTh3D4rk - Mi 02.03.05 16:26

dann wären es aber immer noch 2,425 sekunden :D


retnyg - Mi 02.03.05 16:46

Elite hat folgendes geschrieben:
Also um auch mal meinen Senf zum Sinn dieses Aufwandes dazuzugeben:
Das Laden der Hauptseite dauert bei mir 2,5 Sekunden (Rush Hours ausgenommen). Wenn man jetzt 5% Traffic spart, bringt das vielleicht einen Zeitvorteil von nur noch 3%, denn DB-Zugriffe etc. müssen ja trotzdem gemacht werden.
Ich hätte einen Zeitvorteil von 2,5s/100*3 = 0,075s. Wow!
Selbst wenn man man ein paar Zugriffe zusammen addiert, kommt man immer noch nicht auf einen nennenswerten Vorteil. Also wenn Performance verbessern, dann bitte andere Ansatzpunkte!

ne seite hier im DF hat im schnitt sicher 80 - 120 kb
bei uns in .at zahlt man noch ordentlich für jedes gb traffic. 10 seiten-aufrufe im DF machen schon mal 1 MB.
wenn ich also das ADSL-paket (http://www.aon.at) mit 400 MB traffic für 29,90 hätte könnte ich vermutlich schon nach 2 wochen ein zusatzpaket kaufen.


F34r0fTh3D4rk - Mi 02.03.05 16:49

ich hab 1gb und kein problem ich zock auch online, benutz nebenbei ts2 und icq und forum, und andere seiten und das geht...


Delete - Mi 02.03.05 16:51

Also über den Telekom Backboune ist das Peering zu Serverkompetenz/Strato ja auch ziemlich gut, wenn ich mich über Terralink oder Celox einwähle hab ich oft Probleme bei den Strato Servern!

Bei mir liegts aber am Anfang (Also das Problem mit dem Aufbau der Seite) an der IP DNS Umleitung zu delphiprojekt.de welches von delphi-forum.de aufgerufen wird!

Kidix


neojones - Mi 02.03.05 16:55

@Kidix: Wie kommst etz auf Strato? Das hat damit doch gar nichts zu tun.


Delete - Mi 02.03.05 16:59

neojones hat folgendes geschrieben:
@Kidix: Wie kommst etz auf Strato? Das hat damit doch gar nichts zu tun.


also laut dns wird delphiprojekt.de auf strato serverkompetenz servern gehostet! Und zwar bei Strato in Berlin!

Kidix

P.S: Hier die Route von delphi-forum.de

Screenshot [http://kidix.funpic.de/terra.htm]


Tino - Mi 02.03.05 17:26

Bitte beim Thema bleiben!