Suche

[FrankySZ]

Hi @ll,

in Ahnlehnung an diesen doch schon etwas alten Thread http://www.pragmamx.org/modules.php?name=Forum&topic=11340.0

hat schonmal jemand Erfahrung mit 600-800 Usern online gemacht?

Eine Seite die ich unterstuetze lief so 1,5 std,  dann hat der Hoster die Site abgeschaltet mit dem lapidaren Hinweis das da wohl  "ein" script einen Fehler verursacht haette    ... selbsverstaendlich ohne Nennung eines konkreten Scripts.

Die site verwendet die pragmaMx 0.1.7 standartinstallation

Kann sich zufaellig jemand nen script aus dem pragma denken, dass nach 1,5 std aufhoert fehlerfrei zu funktionieren?

btw. Was soll man von so einem Hoster halten?

[FrankP]

Eine Fragestellung, über die man unendlich diskutieren kann und doch zu keinem Ergebnis kommt. Die Performance einer Website muss individuell je Website diskutiert, analysiert und optimiert werden.

Wir hosten ja nun einige mx und aus unseren Erfahrungen ergibt sich folgendes:
-Das mx selbst macht nicht mehr Last, als von derartigen Scripten zu erwarten wäre
-Einzelene Module, vor Allem wenn es um Interaktion geht, machen bei grösseren Besucherzahlen extreme Last und sind sehr schwer zu hosten.
-Allgemeine Beispiele: Exzessiv genutzte PN, nichtoptimierte whoisonline, grosses Coppermine, Usergästebuch ohne Indexierung, Einbindung externer rss-feeds.

Ebenso individuell ist wohl die Einstellung zu der beschriebenen Vorgehensweise des Hosters. Es gibt Kunden, die so etwas tolerieren, andere tun dies nicht. Die 1,5 Stunden kommen kaum von einer "Halbwertszeit" eines Scriptes, sondern ist wohl eher die Zeit, die der hoster benötigt hat, herauszufinden, wer die Last macht 

[FrankySZ]

Hi FrankP,

Eine Fragestellung, über die man unendlich diskutieren kann und doch zu keinem Ergebnis kommt.

jep damit wirst du wohl recht haben ...

thx fuer deine Infos zu den bei euch gehosteten mx und euren Erfahrungen ... und den Beispielen, dann weiss ich schonmal wo ich evtl. noch ansetzen kann ..

Die 1,5 Stunden kommen kaum von einer "Halbwertszeit" eines Scriptes, sondern ist wohl eher die Zeit, die der hoster benötigt hat, herauszufinden, wer die Last macht   

jep das denke ich auch, aber wenn ich eine site hosten wuerde, dann denke ich, ich kann dem Kunden auch klipp und klar sagen, woran es liegt ... zB an der hohen serverlast ....

dubiose Antworten "wie da is nen script das nen Fehler macht" ...  damit kann wohl kaum jemand was anfangen auch wenn mir klar ist, dass der Hoster evtl nicht die Moeglichkeit hat ein script zu bennenen aber was spricht gegen klare Aussagen ....

aber wie du schon gesagt hast ein unendliches thema  .... daher nochmal thx fuer deine Infos

[selin01]

Interessant wäre es doch sicherlich, zu wissen, welche Punkte auf jedenfall umgesetzt werden müssen.

FrankP sprach davon dieses und jenes zu beachten. Es muss doch machbar sein, eine Liste von NOT-TO DO zu erstellen was Module angeht, sowie eine TO-DO Liste was Serverseitig zu beachten ist.

Da wir alle das selbe CMS benutzen, wird es sicherlich einige Eckpunkte geben, an die man sich zu richten hat. Sicherlich hat FrankP recht, das jeder Server anders spinnt, aber gerade FrankP als Hoster kann sicherlich Goldene Tipps und Tricks verraten wie man den eigenen Server soweit optimieren kann, das es nicht Server-abhängig ist.

Das Grundsystem ist doch immer das selbe .....

[FrankySZ]

Hi @ll,

@selin01
nen Anfang ist ja schon hier http://www.pragmamx.org/modules.php?name=Forum&topic=14345.0 gemacht

aber du hast recht, waere klasse wenn FrankP oder wer auch immer damit schon Erfahrung hat uns einige "Goldene Tipps und Tricks" verraten koennen ...

aber dann denke ich, nicht in diesem Thread sondern in einem speziell dafuer gedachten ....

[FrankP]

Ich helfe sehr gerne, soweit ich das kann. Um eine Site aber wirklich zu optimieren, benötigt man einen ServerAdmin *und* einen Programmierer ( oder einen wie jubilee, der beides kann ). Bei uns läuft das im Team, denn ich kann kein Stück programmieren, wohl aber Server frisieren. Wenn ich ein Problemkind habe, sitzt mir gegenüber ein Programmierer, dem ich die Infos, die ich aus tools wie top, mytop, phpmyadmin usw. bekomme, aufbereite und weitergebe. Er analysiert dann den Code, ich bereite diese Infos "kundengerecht" auf und informiere den Kunden, wo er ansetzen muss. Gleichzeitig fange ich Codeprobleme und zu dünne Hardware  mit Änderungen in der http.conf und mysql, selten auch in der php.ini ab. Dieses machen wir ständig, bei allen belasteten Kundenservern ( auch wenn der Kunde root-Zugriff hat aber dies wünscht ) schauen wir solange, bis wir nichts mehr rausholen können und überprüfen Veränderungen regelmäßig und passen die Konfigurationen dann ggf. an.

Insofern kann ich bei externen ( Nichtkunden von uns ) nur allgemeine Hinweise zur Serveroptimierung geben. Hier kommt es zuerst darauf an, ob der Server hinsichtlich der CPU oder eines zu knapp bemessenen RAMs eine zu hohe load erfährt. Standardmaßnahmen sind:

1. httpd.conf für Apache 1.x: KeepAlive muss On sein
-MaxKeepAliveRequests hochsetzen ( in 50er Schritten ) spart CPU, kostet RAM
-KeepAliveTimeout  hochsetzen ( in 5er Schritten ) spart CPU, kostet RAM
-MaxRequestsPerChild hochsetzen ( in Verdoppelungsschritten beginnend bei 100 macht meist Sinn) spart CPU, kostet RAM
umgekehrt, runtersetzen der Parameter dreht die Wirkung um. Nach jeder Änderung den Apache restarten.
2. my.cnf: eine my.cnf muss vorhanden sein ( /etc )
-Wir können mit einer vorgefertigten my.cnf aus den supported-files beginnen.
-Da wir von mysql-lastigen Systemen ausgehen, kann man
medium.cnf bei 512 MB RAM, large.cnf bei 1024 MB RAM und huge.cnf bei 2048 MB RAM nehmen, ggf. grösser, wenn RAM zum Cachen vorhanden ist.
-bei belasteten Systemen die bin-logs abschalten: log-bin aukommentieren.
-einfügen der Zeile query_cache_type = 1
Danach mysql restarten ( bitte nur bei vorher gestopptem Apache )

Das sind jetzt die ersten groben Maßnahmen, für diejenigen gedacht, die einen nichtkonfigurierten Server ausgeliefert bekommen haben um die Kiste erstmal überhaupt ans Laufen zu bekommen. Wenn das gemacht ist, heißt es Schräubchen drehen und code optimieren, bis es passt.