pragma - Tuning-Tip für die nächste Version .... block who is online

[Gast]

Willkommen Gast. Bitte einloggen oder registrieren.

Einloggen mit Benutzername und Passwort

[KeinenPlan]

Hallo,
ich weiss nicht wo ich das reinschreiben soll, deswegen habe ich es jetzt mal in diesem Forum gemacht, notfalls bitte verschieben.
Vorgeschichte:
Ich betreue eine Seite, die bei hoher Besucherzahl sehr langsam wird, um nicht zu sagen, unerträglich langsam. Nun hab ich mich mal mit ein paar Optimierungs-Spezialisten unterhalten. Und zusammen haben wir mal das pragma unter die Lupe genommen, evtl gibt es da einige Anregungen, die für spätere Versionen interesssant sind, um Performance Gewinne zu erzielen.
Also wie gesagt: Seite extrem lahm bei vielen Usern und Gästen (mehr als 100 z.B.), CPU quasi komplett ausgelastet, Load Average geht in die Höhe etc.
Wir haben dann mal den Who is Online Block komplett entfernt, bzw deaktiviert, und die Seite ist trotz über 100 User "gesprintet", also haben wir den genauer untersucht .....
Pferdefuß ist da die Abfrage nach den ganzen Mitgliedern - bei hoher Mitgliederzahl (und die Seite hat eine 5-stellige Mitgliederzahl) erzeugt durch die permanente Einbindung bei allen Seiten enorme Last.
Nun die Überlegung, den Block evtl als Pop Up laufen zu lassen, oder nur auf der Startseite, Problem allerdings ist, dass diese Liste enorm genutzt wird um andere User anzutexten, zu schauen wer online ist, also keine passende Lösung.
Dann eben die entsprechenden Teile aus dem Block auskommentiert (Alle MItglieder) und seitdem geht es wirklich wieder super fix ....
Nun die Anregung von den Optimierern, die das abe rleider nciht für mich machen, und da ich keine AHnung habe, weiss ich nicht was ich zu machen habe:
Die meinten:

sowas kann man weit effezienter loesen - z.b muss man das nicht ausrechnen, sondern kann GENAU diesen einen wert in der db halten
und mit jeder anmeldung um 1 erhöhen.

Wäre das nicht einbaubar für die nächste Version des pragma? Gerade für mitgliederreiche Communitys würde das einen enormen Performance Gewinn bringen ....

Also, das war es schon ;-)

[NeMeSiSX2LC]

Hm muss mal auf meiner testen.. zwar keine 5szellige user zahl aber eine 4 stellig tuts ja auch

[KeinenPlan]

Also definitiv weiss ich, dass dadurch enorme Performance Geiwnne erzielbar sind je mehr Mitglieder auf einer Seite sind ....

Load Average vorher ca. 9-19
Load Average nachher ca. 1.08 - 2.50

Ich denke der Performancegewinn ist schon gravierend!
Nur leider kann ich das nicht umsetzen, ich hab jetzt mal die entsprechenden zeilen vorerst mal auskommentiert im Block .... (nicht nur die Ausgabe, sondern auch die Abfragen)

[NeMeSiSX2LC]

Überleg schon aber bis auf das "alterstatistik" module einsetzen. Ist mir bisher nix besseres gekommen...

[FrankP]

Habe heute ausführliche Tests an einer Community mit ca. 100 gleichzeitigen Usern gemacht. Kann das Problem bestätigen. Load mit whois_online: 7 bis 15, load ohne 0.5 bis 1.5 bei identischer Konfiguration des Servers.

Der Vollständigkeit halber: Sonst ist keinerlei Lastiges festzustellen, UserGb macht etwas Dampf, doch einigermaßen durch caching abzufangen.

[KeinenPlan]

wie gesagt, nur ein gedankenanstoß - ich kanns leider nicht coden.
nur wieso sollten wir (ich meine damit alle pragma-begeisterten) nicht gemeinsam schauen, wo noch eine möglichkeit besteht, das dingens etwas zu "tunen" ;-)
nachdem ja schon des öfteren zu lesen war "meine seite ist lahm" und so weiter, evtl hilft das, also hier ist der gewinn enorm gewesen, siehe oben ...es giubt noch ein paar andere ansätze, die wir noch die tage oder wochen mal abchecken, ich werde dann wieder euch unterrichten, evlt ist da ja was "einbaubares" - wäre doch gut, wenn das pragma immer schneller werden würde ;-)
und oft sind es kleinigkeiten, wurde mir gesagt, die enorme lasten verursachen, und die man durchaus - etwas anders programmiert, bzw etwas anders ausgeführt - "schonender" laufen lassen könnte ....

[Atze]

@KeinenPlan

Muß mich auch mal einmischen.
Welche Zeile hast den im whoisonline - Block auskommentiert???
Würde mich interessieren?

Danke
Gruß

[KeinenPlan]

die hier alle hab ich rausgeworfen:

Code: [Select]  

# Anzahl aller User und hoechste uid ermitteln
// $totalmembers=0;
// $qry="select COUNT(uid), MAX(uid) from ${user_prefix}_users where user_stat=1;";
// list($totalmembers, $lastuid) = sql_fetch_row(sql_query($qry));

# neusten User ermitteln
// $lastuid = (empty($lastuid)) ? 0 : $lastuid;
// $qry="select uname from ${user_prefix}_users where uid = $lastuid;";
// $result = sql_query($qry); # neusten User ermitteln
// list($lastuser) = sql_fetch_row($result);

(ca. zeile 68 ff)

und hier noch:

Code: [Select]  

##."\n<tr>\n<td class=\"boxcontent\">"._BWOTOTALMEMBERS."</td>\n<td align=\"right\" class=\"boxcontent\">\n<b>$totalmembers</b></td>\n</tr>\n"
##."\n<tr>\n<td class=\"boxcontent\">"._BWOTODAYMEMBERS."</td>\n<td align=\"right\" class=\"boxcontent\">\n<b>$userCount</b></td>\n</tr>\n"
##."\n<tr>\n<td class=\"boxcontent\">"._BWOYESTERDAYMEMBERS."</td>\n<td align=\"right\" class=\"boxcontent\">\n<b>$userCount2</b></td>\n</tr>\n"

ca zeile 178 (ausgabebereich)


sonst glaub ich nichts mehr ...

[NeMeSiSX2LC]

Hab grad mal ein Stress tool angesetzt also bei 350 User is da schluss da kommt nix mehr... selbst bei 150 tut sich seeehr wenig

[KeinenPlan]

was meinst du mit stress tool ?
bei "besucher-generator" für deine seite um das auszutesten ?
wie ging es vorher ? wie danach ?
kannst du mir das mal zukommen lassen evtl. will das dann auch mal austesten!!
gerade sinds ca. 60-70 mitglieder und ebensoviele gäste nochmal und es läuft erste sahne hier ;-)
(also im vergleich zu vorher ....)

[NeMeSiSX2LC]

Ne das teil ist bissel unrealitisch.... Weil bei 350 Usern meldet eine vkpMX2.1.b installation das die Seite nicht mehr angezeigt werden kann und eine 0.1.6 installation haut mir die meldung raus das mit der DB was nicht stimmt....

[onkel]

Was passiert wenn man den block cacht?

[Andi]

Moin

bevor dieser interessante thread wieder irgendwie zerlabert wird....

Definitiv geht es hier um diese Datenbankabfrage:

Code: [Select]  

select COUNT(uid), MAX(uid) from ${user_prefix}_users where user_stat=1;

Für mich ist es ein Rätsel, warum ausgerechnet dieses primitive Ding soviel Serverlast erzeugen kann.

Bevor wir weiterrätseln und irgendwelche unbedachten Schlüsse ziehen, schau mal bitte in der Tabellendefinition per phpMyAdmin o.Ä. ob die Indexe der User-Tabelle korrekt sind.
- Bitte je einmal die tabelle reparieren und optimieren lassen.
- Dann in den Tabelleneigenschaften nachsehen, ob diese 3 Indexe wie folgt existieren:

Indizes:
Name      Typ         Kardinalität  Feld
PRIMARY     PRIMARY   2                 uid
uname        UNIQUE     2                 uname
user_stat     INDEX       keine          user_stat

Dass man die Anzahl der User, d.h. die Anzahl der User in der Datenbank zwischenspeichern kann ist zwar richtig, es widerspricht aber allen Regeln der Datenbankprogrammierung > Stichwort Redundanz.
Ok, da es sich natürlich nicht um wirklich wichtige Daten handelt, auf einen User mehr oder weniger kommt es eh nicht an, kann man darüber hinwegsehen...
Aber, erst guggen wir, ob es nicht auch anders geht...

[KeinenPlan]

Also, da kenn ich mcih jetzt nicht so aus ....
Aber so wie ich das sehe steht da bei Kardinalität eben die Anzahl der User (also irgendwas im 5-stelligen Bereich bei mir) - also bei Primary und uname ....


Klar wäre es mir egal, wenn die Anzahl der User um ein paar nicht stimmt, evtl wäre das ja durch tägliches bzw nächtliches Update (cronjob vielleicht oder sowas) möglich zu umgehen, genauso wie die gestern registrierten und heute registrierten (die dann eben weglassen) ....

[Andi]

Hi

die Kardinalität ist nebensache...
Sind die 3 Indexe, abgesehen von der Kardinalität, exakt so vorhanden und ist die Tabelle repariert?

[KeinenPlan]

die ersten beiden ja, dann noch ein paar andere, aber user_stat nicht !
repariert: ja

[KeinenPlan]

stop.
bei uname ist der "Typ" -index und nicht unique.

[Andi]

aha, ist ja schonmal was... 

führe mal bitte die folgenden 2 Befehle im phpMyAdmin sql-Fenster aus.
Für {user_prefix} natürlich den entsprechenden prefix verwenden

ALTER TABLE `{user_prefix}_users` DROP INDEX `uname` , ADD UNIQUE `uname` ( `uname` ) ;

ALTER TABLE `{user_prefix}_users` ADD INDEX `user_stat` ( `user_stat` ) ;


Dann bitte nochmal ausgiebig testen, ob sich was verändert hat.

[NeMeSiSX2LC]

Was soll man den tun wenn das alles schon so ist wie du es gesagt hast? Aber die Seite totzdem langsam wird?

[KeinenPlan]

also, Fehler
user_stat existiert nun.
aber sieht nicht anders aus so, also auch der load hat sich nicht erniedrigt ....
bin wieder zurück zum auskommentieren übergegangen .....