Suche

[Andi]

also, Fehler

Was bedeutet das?
Existiert der uname Index noch nicht als Unique?

Ist es dir möglich, mal 3-4 verschiedene Blöcke nacheinander durchzutesten?
Habe da ein paar Gedanken wie man da was ändern könnte.....

Versteh mich bitte, dass ich erstmal versuche das Problem über die Tabelle und den Block zu lösen.
Ich sehe im Moment nicht ein, das System dermassen umzubauen, nur wegen dieser komischen Funktion, die in einem ernsthaften CMS eigentlich garnicht benötigt wird.
Wenn sich das Problem über eine Änderung des Blocks lösen lässt, ist das für mich ok, aber an den Systemdateien und den beteiligten Modulen will ich da möglichst nicht schrauben....

[KeinenPlan]

keine Ahnung was ich mit Fehler meinte ?!?!?
ja, ich könnte 3 blöcke schon durchtesten, wäre kein problem ....
Welche soll ich testen?
Im MOment ist aber nicht mehr soo viel los, also ich sehe das dann immer "zeitverzögert" ..... weil ich nur alle paar Minuten einen neuen Wert für den Load Average (und auch cpu auslastung) bekomme (load z.z. bei ca. 0,3 ). aber evtl merkt man das ja dann auch direkt beim surfen .....

[Andi]

Oki, ich werde dann mal 2-3 verschiedene Blöcke basteln, die zwar alle das gleiche tun, aber über verschiedene Wege. Nur mal um zu sehen, an welchem Teil der Datenbankabfrage wirklich das Problem ist.
Glaub aber nicht, dass mir das jetzt noch reicht.
Ich hänge die Dateien dann einfach hier als Anhang dran.
ok ?

[KeinenPlan]

alles klar ;-)

[Andi]

ok, ist garnicht so kompliziert....
Hier die Nummer 1

[gelöscht durch Administrator]

[KeinenPlan]

also block läuft, in ca. 10 min sollte ich die ersten auswirkungen sehen - anhand der load/cpu anzeige.
leider ist kaum mehr was los, so muss ich auf die daten warten .....

[KeinenPlan]

also. man merkt es doch shcon selber beim surfen, die seite wird wieder langsamer .....
load und cpu sind auch etwas höher wieder vor allem der load, also der block bringt so keine besserung, ich hau mal wieder den von mir rein ....

[Andi]

jop, dass der unterschied zum auskommentierten Block negativ wird ist nicht mehr als logisch.
Es geht ja darum, den Unterschied zum Original festzustellen.

Hier die nummer 2
wobei ich eher an diese Änderung jetzt glaube...

[gelöscht durch Administrator]

[KeinenPlan]

also, ist schon mal vom gefühl her auf jeden fall merklich langsamer ....
daten kommen gleich .....

[KeinenPlan]

ist nun quasi kaum noch messbar.
aber vom gefühl(!!)  her, ist dein zweiter block schon etwas fixer als der ursprüngliche, aber bei weitem nicht bei dem modifizierten .....
die werte deuten auch darauf hin, ist aber wie gesagt nur noch im "milli"-bereich - kann also auch eher auf zufällig sein, weil gerade ein oder zwei user mehr oder weniger drauf ist .....

[Andi]

So, dann nimm mal bitte noch den  dritten. Habe gerade gesehen, dass der 2te garnicht optimal war...

Mehr ist aus dem Block jetzt eigentlich nicht mehr rauszuholen.
Wäre interessant zu wissen, was das Teil jetzt unter Vollast macht.

[gelöscht durch Administrator]

[KeinenPlan]

Volllast gibt es aber erst wieder morgen ;-)
Ich schau mir den jetzt mal an - dann kommt ne Gefühlsaussage, und morgen werde ich ihn mal für ne gewisse Dauer und Last einsetzen - je nachdem was der Block so "packt" ..... bzw. ob er zumindest eine annehmbare Surfgeschwinsigkeit erlaubt ....

[Andi]

Jop, das ist klar, immer mit der Ruhe
Wenn das nix bringt, dann sag ich mal ganz krass, ist entweder der Server bzw. dessen mysql-Einstellungen ne Niete oder mySql selbst ist ne Fehlkonstruktion.
Weil, wenn solche primitivqueries:

Code Auswählen Erweitern

select COUNT(uid) from ${user_prefix}_users where user_stat=1;
select uname from ${user_prefix}_users where user_stat=1 ORDER BY uid DESC LIMIT 1;
..so ein Loch verursacht, dann hängt da prinzipiell was

[KeinenPlan]

Also Load und CPU-Auslastung ist n Tick niedriger, als beim Ursprungsblock, aber schon n guten Tick höher, wie beim von mir modifizierten .....
Aber wie gesagt - viel zu wenig los, als dass man da ne wirkliche Aussage treffen könnte.
Aber mein Surfgefühl bestätigt die Zahlen ....
Ich denke schon, dass Dein dritter Block viel bringen wird, aber um mehr Performance rauszuholen sollte man das irgendwie anders lösen ?!
Evtl. ein Extra Block, der gecached ist und auf ne Stunde eingestellt wird, oder sowas ?
Ist mir nur so als "Nachtgedanke" noch gekommen ..... auch weil ich gerade in nem anderen Thread Deine Ausführungen über das Caching gelesen habe ....

[KeinenPlan]

Also ob der Server oder SQL ne Niete ist, kann ich niht wirklich sagen .....
Also laut den Aussagen der Leute, ist der Server sauber und ordentlich eingerichtet (die haben da wie ich evtl shcon gesagt habe drübergeschaut), es besteht zwar noch Verbesserungspotenzial - klar - aber grundsätzlich müsste alles Grobe ganz ordentlich eingestellt sein, ich weiss aber nicht ob die schon die sql Einstellungen gecheckt haben, bzw die haben die heute mal durchforstet, kein Plan,w as da rausgekommen ist,m weil ich mit dem who is online block beschäftigt war
Werde ich aber morgen erfahren .....
Und dann teste ich mal die dritte Variante unter großer Last / Vollast... gerade wenn die dabei sind, weil die haben Realtime-Stats, da geht die Auswertung auch ein bissle schneller ;-)

[Andi]

Moin

klar, so krass war das mit der Niete auch nicht gemeint, es ging auch nur um dem mysql-server bzw. dessen Einstellungen. Davon habe ich auch viel zu wenig Ahnung um das beurteilen zu können.

Sorry, aber wir hatten hier vor kurzem ein ähnliches Problem mit dem SMF Forum, unser vorheriger Provider präsentierte uns auch immer bestimmte Queries des SMF, die allerdings bedeutend lastiger waren als diese beiden primtivqueries. Das waren dann solche Dinger:

Code Auswählen Erweitern

SELECT m.posterTime, ms.subject, m.ID_TOPIC, m.ID_MEMBER, m.ID_MSG, b.ID_BOARD, b.name AS bName, IFNULL(mem.realName, m.posterName) AS posterName, 1 AS isRead, 0 AS logTime
FROM mx_org_smf_messages AS m, mx_org_smf_topics AS t, mx_org_smf_boards AS b, mx_org_smf_messages AS ms
LEFT JOIN mx_org_smf_members AS mem ON (mem.ID_MEMBER = m.ID_MEMBER)
WHERE m.ID_MSG >= 87237 AND t.ID_LAST_MSG = m.ID_MSG AND b.ID_BOARD = t.ID_BOARD AND FIND_IN_SET(-1, b.memberGroups) AND ms.ID_MSG = t.ID_FIRST_MSG
ORDER BY m.ID_MSG DESC aus dem SMF Centerblock, welcher bei uns auf der Startseite läuft.
Das ganze Forum war dort mit der Zeit unerträglich langsam geworden. Und siehe da, hier rennt es wieder...

Ich will dir keinesfalls den provider madig machen, aber wie du selbst schreibst, irgendwo muss noch Verbesserungspotential sein. Ist ja super, dass man dich dort so prima betreut. Wir mussten wechseln....

Evtl. ein Extra Block, der gecached ist und auf ne Stunde eingestellt wird, oder sowas ?

Das wäre natürlich auch eine gute Lösung. Die normale Statistik, die ja hier das Problem verursacht aus dem Onlineblock auslagern. Denke das wäre für alle Seiten die beste Lösung, weil wie schon gesagt, wegen der komischen Userstatistik will ich nicht unbedingt das System mit Schnickschnack beladen...

[KeinenPlan]

Naja, ist ja nicht der Provider selber, der das macht, sondern ein paar Jungs die da echt fit sind ....
Wobei der Provider auch sehr sehr entgegenkommend ist. Aber die Jungs schauen sich eben alles an, also das komplette Paket, samt der Seite selber, nicht nur die Hard- und installierten Sachen.
Die haben mir eaccelerator oder sowas in der art installiert, hat zwar nicht so viel wie erwartet gebracht, aber immerhin eine Senkung der Last um ca. 20% - also ist das durchaus eine Empfehlung auch für alle anderen ;-)
Nun gut, und da die ganzen "groben" Verbesserungen nichts gebracht haben, haben die jungs sich mal genauer mit den Abfragen beschäftigt, und sind eben dazu gekommen, dass viel Last von dem Block aus geht .....
Hardwaremäßig und die installierten Sachen meinten die allerdings, sei vollkommend ausreichend für viel viel mehr, also haben die durchaus auch Kritik am pragmamx geäußert - aber nun gut, ich denke überall herrscht verbesserungspotenzial. und wenn da alle irgendwie erfahrungen sammeln und einbringen, kann man durchaus auch einen fortschritt step by step an "allen fronten" erzielen - sei es hardware, installierte sachen, oder eben auch das cms ;-)

Aber das mit dem Auslagern wird mir immer sympatischer! Leide rhab ich dazu wie immer viel zu wenig Plan um das selber zu realisieren, evtl bringt ihr eine Aufsplittung des Moduls in eine Eurer nächsten Versionen mit rein!?

achja, hab vorhin im phpmyadmin gesehen, dass die da was gemacht haben, sieht anders aus, glaube die haben da auch ne neue version draufgehauen - mal sehen was die morgen sagen ....

[FrankP]

Wie gesagt habe ich mich gestern zum ersten Mal ausführlich mit einem grösseren pragma auf einem dedicated Server beschäftigt - siehe diesen Thread: http://www.pragmamx.org/modules.php?name=Forum&topic=14341.0.
Die Problemstellung war, herauszufinden, warum ein Serverpaar Xeon 2,8 mit 1024 MB RAM als DB-Server und ein Webserver Athlon 2400+ mit 512 MB RAM  ab 60 User vollkommen überlastet ist. Als Testumgebung wurde das pragma auf einen einzelnen Athlon 2200+ mit 1024MB RAM aufgespielt und mit Standardkonfiguration produktiv gestellt. Diese Hardwareausstattung hatte ich als ungefähr ausreichend für ein pragma mit ca 120 GB Traffic/Monat erachtet. Ziel war, ohne Einschränkungen in der Funktionalität einen vertretbaren Kostenaufwand für das Hosting ( Hardware ) zu realisieren.

Nachdem vordergründig lastige Queries des PN und des UserGB mit Caching und Änderungen in der Serverkonfiguration in den Griff zu bekommen war, blieb der whois-online Block, den ich mit serverseitigen Änderungen nicht in den Griff bekommen konnte. Bei ca. 80 Usern ( 50 Mitglieder / 30 Gäste ) war der Server nicht mehr handlebar, die load ging bis auf über 15 ehe ich eingriff. Ohne den Block lief der Server mit einer load von im Schnitt 1.0. bei vergleichbarer Userzahl.

Ergebnis: das pragma als Ganzes konnte bei der vorliegenden Instanz keinesfalls als lastig bezeichnet werden, wobei das Forum eher schwach ferquentiert wurde und darüber keine Aussage getroffen werden konnte. Insbsondere das anfänglich unter "Verdacht" stehende PN ist durch query_cache_type = 1 und andere Cachingmethoden ( MMCache u.ä.) bzgl. der Last irrelevant. Lediglich das UserGb, das ja offensichtlich nicht mehr in der Standardinstallation enthalten ist ( ? ) , konnte nicht sauber gecached werden und verursacht ( noch erträgliche ) Lastspitzen. Übrig bleibt der whois_online Block, der sich beharrlich weigerte, serverseitige Optimierungsroutinen anzunehmen.

Empfehlung an den Kunden war, den Block umzuprogrammieren und solange nicht einzusetzen. Als Hardwareausstattung wird eine 3 GHZ CPU mit 1024 MB RAM empfohlen.

Vielleicht könnte man bei Interesse eine Zusammenarbeit zwischen dem pragma Team und dem Kunden anstreben, um im laufendem Produktivbetrieb Optimierungungen in der Programierung zu testen.

Ich hoffe, ich konnte hiermit etwas zu der Diskussion beitragen 

Nachtrag: ooops, sorry, ist mir irgendwie zweimal reingerutscht 

[jubilee]

Hallo !

Lediglich das UserGb, das ja offensichtlich nicht mehr in der Standardinstallation enthalten ist ( ? ) , konnte nicht sauber gecached werden und verursacht ( noch erträgliche ) Lastspitzen

Wird aber nur Abgefragt, wenn sich auch jemand das Usergästebuch anschaut.
Also keine Datenbankabfragen nach Zeit bzw. bei Seitenreload.

MfG
jubilee

[FrankP]

Korrekt - deshalb ja auch Lastspitzen und keine Dauerlast wie beim whois_online Block.
Sie lassen sich teilweise mit serverseitigen Konfigurationen eingrenzen, benötigen aber in letzter Konsequenz mehr CPU-Zeiten und deshalb - um die Performance *stets* zu erhalten, eine etwas stärkere CPU.