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:
Zitatsowas 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 ;-)
Hm muss mal auf meiner testen.. zwar keine 5szellige user zahl aber eine 4 stellig tuts ja auch ;)
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)
Überleg schon aber bis auf das "alterstatistik" module einsetzen. Ist mir bisher nix besseres gekommen...
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.
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 ....
@KeinenPlan
Muß mich auch mal einmischen.
Welche Zeile hast den im whoisonline - Block auskommentiert???
Würde mich interessieren?
Danke
Gruß
die hier alle hab ich rausgeworfen:
# 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:
##."\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 ...
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 :(
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 ....)
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....
Was passiert wenn man den block cacht?
Moin :)
bevor dieser interessante thread wieder irgendwie zerlabert wird....
Definitiv geht es hier um diese Datenbankabfrage:
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...
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) ....
Hi :)
die Kardinalität ist nebensache...
Sind die 3 Indexe, abgesehen von der Kardinalität, exakt so vorhanden und ist die Tabelle repariert?
die ersten beiden ja, dann noch ein paar andere, aber user_stat nicht !
repariert: ja
stop.
bei uname ist der "Typ" -index und nicht unique.
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.
Was soll man den tun wenn das alles schon so ist wie du es gesagt hast? Aber die Seite totzdem langsam wird?
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 .....
Zitatalso, 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....
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 .....
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 ?
alles klar ;-)
ok, ist garnicht so kompliziert....
Hier die Nummer 1
[gelöscht durch Administrator]
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 .....
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 ....
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]
also, ist schon mal vom gefühl her auf jeden fall merklich langsamer ....
daten kommen gleich .....
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 .....
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]
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 ....
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:
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
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 ....
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 ;-)
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:
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....
ZitatEvtl. 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...
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 ....
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 ::)
Hallo !
ZitatLediglich 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
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.
Andi, also nun habe ich mal getestet und ein erschreckendes Ergebnis festgestellt .....
Zwar nicht unter Voll-Last, aber doch bei 50% CPU Auslastung.
Ich hatte den von mir modifizierten drin Load Average lag so die ganze Zeit bei 1 - 2
Dann habe ich den ursprünglich wieder rein, also die Veränderungen von mir rückgängig gemacht, Load geht auf ca. 6 bis9 hoch ....
Seite wird schon schwer zu surfen.
Also ich dann den dritten von Dir reingetan habe, ist der Load auf weit über 20 hochgegangen ..... die Seite war nicht mehr ansurfbar ..... Also hast Du da scheinbar de-optimiert, kein Plan, was da los war, ich bin nun wieder beim von mir ursprünglich modifizierten, und der Load ist wieder unter 2 ......
Moin :)
was dann die Qualität des originalen Scriptcodes des Onlineblocks bestätigt ;)
Unter diesen Umständen wird als einziger Ausweg die Trennung des Blockes in 2 verschiedene Blöcke bleiben.
vorsichtig nachgefragt welchen who is online block soll man jetzt vorläufig verwenden :-) ???
HI :)
klare Antwort: Das Original
Da dieses Problem bisher nur auf 2 Seiten aufgetaucht ist, kann es momentan keine andere Empfehlung geben.
naja bei mir ist es so wenn ich den block einschalte dann ist mein server mit 50 usern gleichzeitig sehr überanstrengt ...
Zitatbei mir ist es so wenn ich den block einschalte
Naja, das hat mir die Glaskugel nicht gesagt ;)
Probiere die hier im thread angehängten durch. Eine Pauschallösung haben wir leider nicht ;)
Hmmmm ....
Ich glaub ich nehme mir doch noch den Who_Is_Online - Block vor und schreib dafür eine
Ajax/Soap Updateroutine.
.....
um das thema mal wieder aufzugreifen, meine seite ist furchtbar langsam.. und das obwohl ich bei weitem noch nicht so viele user hab wie ihr!
vom server her, dürfte es keine probleme geben, denn meien andere seite auf eben diesem, läuft im normalen bereich!
ich habe auch mal versucht den block "who is online" zu deaktivieren, aber es tat sich da nix! immer noch so saulangsam! an welchen blöcken könnte es noch hängen, oder muß an diesem block tatsächlich was geändert werden?
gibts vielleicht noch andere einstellungen, die mein pragma so langsam machen?
kann mir da bitte jemand weiter helfen?
hier mal der link zu meiner seite: http://www.wave-of-darkness.com/Community/html/index.php (http://www.wave-of-darkness.com/Community/html/index.php)
danke!
Kann jetzt nicht wirklich behaupten das die Seite langsam ist
nicht? hm.. vielleicht liegts daran, wenn ich als admin on bin, das ich da ja mehr blöcke aktiviert habe und die seite bei mir deshalb so langsam läuft!
obwohls im ausgeloggten zustand auch nich bedeutend schneller ist!
ich sollte mal ne umfrage starten unter den usern!
Zitat von: NeMeSiSX2LC am 16 März 2006, 19:35:42
Kann jetzt nicht wirklich behaupten das die Seite langsam ist
kann mich da nur anschliessen :)
Moin :)
http://www.pragmamx.org/News-file-article-sid-608.html
ZitatNachfolgend ein grober Überblick über die wichtigsten Änderungen:
* einige Datenbankoptimierungen
* Spaw Wysiwyg-Editor, kein......
Manchmal frage ich mich, warum wir die Ergebnisse solcher Threads überhaupt in neue Versionen einfliessen lassen....
ups.. sorry andi!
wußt ja nich das des damit zusammenhängen kann!
kann mir da schlecht die zusammenhänge mit meinem problem und der neuen version drunter vorstellen!
bin eh gerade voll daneben und im stress!
tut mir leid! ich glaub ich brauch nen eigenen support für meine ganzen problemchen und fragen! :'(
Hi :)
macht ja nix, ist auch nicht gesagt, dass das in deinem speziellen Fall was bringt.
Wäre halt nur der nächste Tip gewesen ;)
Wobei m.E. die Geschwindigkeit deiner Seite absolut ok ist...
ich werds mal drauf spielen und weiter sehen!