Webseite brutal langsam

    Ich hab kürzlich eine Nachricht bekommen, das das Joomlaportal aufgrund des Spams "tod" ist, also versuch ich hier mein großes, großes Problem zu losen.


    Es geht um das Problem aus dem Joomlaportal: http://www.joomlaportal.de/joo…ion-extrem-langsam-4.html


    Ich habe meine alte J1.5 seite vor einem halben jahr auf j3 migriert. Seit dem hat meine Webseite übelste Performance-Probleme.
    Zwischendurch war es zwar wieder besser, aber die Ladezeiten sind unter aller Sau, zumal ich einen Managed Dedicated Server habe.


    Was mir eben letztens auffiel, ich zehn Artikel gleichzeitig in 10 Tabs geöffnet. Die Ladezeiten waren brutal lang und dann gab es sogar "Error 500 - Internal server error" Fehlermeldungen. Das heißt mein Server war ein paar Minuten tatsächlich down. Nur weil ein Besucher zehn Seiten gleichzeitig öffnet. Das kannst doch nicht sein..


    In der Datenbank liefen zu dem Zeitpunkt, als ich die 10 Seiten geöffnet habe, sehr viele Prozesse mit langen Zeiten:

    Leider kann ich da nicht viel rausinterpretieren.


    Ich hab nur keine Ahnung, wieso meine Webseite so brutal langsam ist. Pagespeed-Tests sagen mir, das die Seite extrem lange braucht bis sie überhaupt erreicht wird. Danach sind die Ladezeiten auch ganz ok. Nur ich weiß einfach nicht, wieso es so lange dauert bis die Seite überhaupt erreicht wird. Liegt das am Server? Oder an irgendwelchen Datenbank-Abfragen...?
    Ich steh zumindest voll auf der Leiter...


    Vielleicht kann mir ja jemand behiflich sein...


    LG

    Hi,
    habe ich das richtig gelesen in dem Screenshot, das du da ein paar TB über den Server schaufelst?
    Das schheint mir dann doch recht viel.
    Wie sind denn deine Zugriffszahlen, wieviel Power hat dein Server?
    Im Firebug hast du gleich zu Anfang eine sehr lange get Anfrage, über 4 Sekunden. Das ist defenitiv langsam, bei mir liegen die im Schnitt so zwischen 0,6 und 1 sec.
    Wie groß ist den die Datenbank?
    Wie cache du das ganze und ist gzip aktiviert?

    WBR from DE-de

    "Hier könnte Ihre Werbung stehen"

    Hallo,
    das muss nicht an Joomla liegen. Erste Anlaufpunkt ist der Server, stimmt hier die Performance ?
    Dann würde ich mal die Banner unter die Lupe nehmen.
    Ist bei der Seite der Cache eingeschaltet ?
    Wie sieht es mit der gzip Komprimierung aus ?

    Ich kenne keine Details und in solchen Fällen sind Mutmaßungen sehr schwer von außen zu machen. Hier muss ein Profi ran der sich mit Joomla und gleichzeitig Servern auskennt.
    Wir haben einen ähnlichen Fall eines Kunden, der einen eigenen (leistungsstarken) Server betreibt auf dem quasi nur seine eigene Seite läuft. Mit Joomla 1.5 lief alles reibungslos und jetzt ist seit ein paar Tagen auf J 3.4 migriert worden. Die Last ist brutal nach oben gezogen und die Seite ist kaum noch nutzbar. Es wurde bereits stundenlang untersucht und momentan mit einem neuen PHP-Opcode-Cache und dem Nonumber Cache Cleaner etwas (oberflächliche) Ruhe in die Situation gebracht. Der erweiterte Joomla-Cache sorgt dafür das sich DB-Queries minimiert wurden, aber das Grundproblem das die PHP-Prozesse extrem CPU-lastig sind, wurde nicht beseitigt. Kommen Bots vorbei und gibt es Peaks bei den Zugriffen, bricht die Maschine gnadenlos zusammen - obwohl baugleiche Server hunderte anderer Joomla mit mehrfach vielen Zugriffen kaum spürbar verarbeiten kann...


    Will damit sagen, das solche Probleme nicht mit Standardtipps von außen gelöst werden können. Hier muss man genau hinschauen und erst einmal die Ursache erkennen. Beispielsweise ob es die Queries sind oder die PHP-Prozesse. Beim Server schauen, was genau überlastet wird. Reicht der RAM nicht aus, swappt die Maschine, ist MySQL optimal konfiguriert usw. Bestimmte Parameter verändern und die Wirkung prüfen (Komprimierungsverfahren, Cache-Techniken, insbesondere die MySQL-Konfig usw.)
    Die Serverhardware wird vermutlich nicht die Ursache sein, wenn vorher mit einer andere Scriptversion alles einwandfrei lief. Wenn es ein typischer Managed-Server einer der großen Anbieter ist (also ohne root-Zugriff), wirst Du keine Chance haben die Parameter des Servers einzusehen oder diese gar zu ändern. Dann heisst es normalerweise: Bitte stärkere Maschine buchen.

    Ich vermute einen Bug mit mootools und Joomla 3.36+ der wahrscheinlich gerade mit der 3.4.1 behoben wurde, vielleicht mit der Ajax-Schnittstelle im Verbund. Im Chrome und Safari läuft die Seite jedenfalls schneller.

    Aktiviere doch bitte die Debug Informationen für Joomla. Außerdem würde auch eine <?PHP phpinfo (); ?> helfen, um grob einschätzen zu können, was schief läuft. Wahrscheinlich habt im Zuge der Migration auch die PHP Version erhöht und Änderungen an der Server Software vorgenommen?! Auch würde die System Plugins im besonderen überprüfen.

    Dieses Rätzelraten ist doch Unsinn. Der Openener muss erst einmal festellen, wo die Überlastung stattfindet. Wird der Server überlastet, dann sieht man das auf dem Server. Die bisherigen Informationen deuten darauf hin, das es auf jeden Fall keine clientseitige Ursache ist. Siehe schon den Screenshot im ersten Postings. Da muss man nun also nicht mit mootools oder großen Bilder etc.pp kommen.

    Huch, danke für die vielen Antworten.
    Also folgendes: Momentan habe ich zwei lästige Problem. Einerseits die sehr lange Zeitdauer bis beim Aufruf der Seite überhaupt der "Erste Connect" da ist. Pagespeed sagt mir da 6 Sekunden. Das ist ja mal unter aller Sau, um es grob auszudrücken.
    Zweitens: Verfasse ich einen Artikel und klicke auf Speichern, muss ich etwa eine Minute warten.
    Ich habe jetzt mal in phpmyadmin auf Status geschaut, welche Prozesse da in dieser Minute laufen

    SQL
    UPDATE xx_content SET ordering = 102 WHERE `id` = '9617'


    Wenn ich auf aktualisieren klicke läuft ein neuer ähnlicher Prozess

    SQL
    UPDATE xx_content SET ordering = 256 WHERE `id` = '8835'


    Also irgendwie sortiert der da was die ganze Zeit.


    Mein Verdacht ist, das es an den assets-Tabellen liegt. Auf englischen Joomla-Seiten wurde sehr häufig darüber disktuiert, das dadurch die Seiten extrem langsam wurden.


    Ich habe zwei Lösungswege gefunden.
    Einserseits: https://docs.joomla.org/Fixing_the_assets_table
    Das habe ich aber schnell aufgegeben. Ich habe knapp 10.000 Artikel in 40 Kategorien. Und das Verschieben (Move) in die temp-Verzeichnisse dauert wieder ewig lange. Wenn ich z.B. 100 Artikel mit der Stapelverarbietung verschiebe, warte ich ca. 10 Minute ehe ich einen "Gateaway: Timeout error" erhalte. Verschoben sind dann zwar rund 50 Artikel, aber der Vorgang würde ja wirklich Tage dauern...


    Zweite Möglichkeit: Mit dem ACL-Manager (kostenplichtig) lässt sich angeblich das assets-Problem lösen. Komponente erworben und begonnen das Reperaturtool laufen gelassen. Wieder hat die Seite 5-10 Minuten geladen ehe dann (glaube ich) der Timout error kam.
    Danach wollte ich im Backenc den ACL-manager erneut aufrufen und erhalte aber eine Fehlermeldung:
    [code] Fatal error: Allowed memory size of 125829120 bytes exhausted (tried to allocate 41 bytes) in /homepages/2/d375415369/htdocs/neu/librarie/joomla/database/[drive]/mysqli.php on line 811{/code]
    Auch nach deinstallieren und neuinstallieren der Komponente komme ich nicht mehr in den ACL-Manager ein. Vom Support kam bisher keine Rückmeldung.


    Das heißt, beide Lösungswege das assets-Problem zu lösen, schlugen vorerst fehl.
    In phpmyadmin sehe ich 53.000 Einträge in xx_assets, einer mit Level 0 (das sollte also zumindest passen).


    Woanders habe ich noch gelesen das die ucm-Tabellen nach der Migration Performance-Probleme verursachen. Ich habe die ucm_history nun geleert und nun dauert das Speichern von neuen Beiträgen nicht mehr ganz so lange. Aber noch immer viel zu lange. Was ich nicht eruieren konnte: Kann ich die ucm_base und ucm_content-Tabellen auch vollständig leeren ohne irgendwelche Probleme zu bekommen? Die Versionshistory brauche ich momentan nicht, wenn die zu viel Balast verursacht.




    du hast leider richtig gelesen. Und das denke ich ist auch das Problem. Liegt wahrscheinlich auch an den Prozessen, die oben beschrieben die ständig laufen
    Zugriffszahlen: Zu Beginn der Woche meist im sehr niedrigen vierstelligen Bereich von den Nutzern.
    Das mit der sehr langen get-Anfrage ist auch das Problem. Ich weiß nicht woran es leigt. Vielleicht liegt es auch an den von mir oben geschriebenen Problem.


    Zum Server kann ich dir nicht viele Daten geben:
    1&1 Dedicated Server DC XL Website
    WebDav:aktiv
    FastCGI:inaktiv
    SSLSupport:aktiv
    Einbindung von Perl als:CGI-Programm
    Einbindung von PHP als:CGI-Programm
    Speichernutzung:131072 kB
    Prozesslaufzeit:360 Sekunden
    Anzahl gleichzeitig ausführbarer Prozesse:100


    Datenbankgröße: 340.591 Datensätze, 121.4 MiB
    Gzip ist aktiviert. Was mir bei den PageSpeed-Tests auffällt, bei Javascript und CSS-Files steht "keine Komprimierung". Wie bekomme ich das hin?
    Cache ist in der Konfiguration "ausgeschalten". Bekam hier auch bereits viele Meinungen zu hören. Mir ist v.a. wichtig, wenn ich etwas ändere, das diese Änderungen sofort sichbar sein. Und wenn der Cache an ist, war das oft nicht so der Fall...

    Ich verwende jetzt schon 6 Jahre lang Joomla und für mich ist die Webseite auch nur ein Hobby. Daher wäre das für mich mein letzter Schritt, einen Profi für viel Geld zu engagieren. Zumal ich meine Kenntnisse selbst weiterentwickeln will, und da ist der beste Weg das Problem selbst anzugehen, natürlich wenn möglich mit Hilfe der Community.
    Und mittlerweile habe ich die Ursachen schon stark eingegrenzt.


    Bezüglich der langen Ladezeit bin ich mir mittlerweile sicher das das mit dem assets-Tabellen-Problem einen Zusammenhang hat.
    Wie bereits im letzten Beitrag erwähnt, fielen mir beim Status in phpmyadmin diese Ordering-Abfragen beim Speichern eines Artikels auf. Die gingen übrigens numerisch bergab. also von etwa 10.000 auf null. Habe ich in einer Kategorie sehr wenige Artikel ist der Artikel auch schneller gespeichert, da weniger dieser Ordering-Abfragen laufen.
    Nur stehe ich momentan auf der Leiter, weil beiden oben beschriebenen Lösungswege momentan nicht fruchten. bzw. der Erste viel zu langwierig wäre...

    Erstes Problem ist zumindest zum Teil gelöst:
    Die lange Wartezeit beim Speichern eines Artikels
    Dieser DB-Befehl hat geholfen:

    SQL
    DELETE FROM #__assets WHERE `name` LIKE '%com_content.article.%';


    Quelle: http://www.itoctopus.com/creat…sets-table/comment-page-1


    Wenn ich speichern klicke, sehe ich in der DB zwar noch immer teilweise die UPDATE SET ordering Prozesse, aber deutlich weniger. Bei einer Kategorie mit 5.000 Artikel (der höchste mit ID 10.500) sehe ich in phpmyadmin 3-4 Mal ordering-Abfragen bis ca. 9.000 ehe der Artikel gespeichert ist. Die ordering-Abfrage laufen also nicht mehr bis 1 runter...
    Also wirklich schlau werde ich daraus nicht. Zumindest ist die Performance im Backend jetzt ein bisschen besser...


    Aktuell ist die Pagespeed (http://www.pagespeed.de/) auch ganz ok bei mir (2-3sek), wobei der erste Connect bei mir schon seit längerer Zeit bei 6,2 sek angezeigt wird. (logisch betrachtet, kann das aber nicht stimmen)

    Nur mal so zum Spaß, welche PHP Version, welchen MySQL Treiber und habt ihr einen opcache an? apc(u) z.B.?


    Man kann Joomla schon mit apc, mysqli statt mysql (in der configuration.php) und einem aktuellen MySQL Server (5.5+) um einiges Performanter machen.
    Die Sessions noch in den Memcache (mittels php-memcacheD, nicht php-memcache) wenn eh nur eine Seite auf dem Server läuft.


    Und dann kommt ja noch das MySQL Tuning selber, eine standard Installation von MySQL ist bei vielen zugriffen völlig unbrauchbar.
    Ich arbeite z.B. regelmäßig mit MySQLTuner und TuningPrimer um meine MySQL Server Einstellungen an die Anzahl der darauf laufenden Seiten und erhöhten Zugriffszahlen anzupassen (etwa alle 1-2 Monate kontrollier und korrigier ich das).

    Zitat von b2un0

    Nur mal so zum Spaß, welche PHP Version, welchen MySQL Treiber und habt ihr einen opcache an? apc(u) z.B.?


    Man kann Joomla schon mit apc, mysqli statt mysql (in der configuration.php) und einem aktuellen MySQL Server (5.5+) um einiges Performanter machen.
    Die Sessions noch in den Memcache (mittels php-memcacheD, nicht php-memcache) wenn eh nur eine Seite auf dem Server läuft.


    Und dann kommt ja noch das MySQL Tuning selber, eine standard Installation von MySQL ist bei vielen zugriffen völlig unbrauchbar.
    Ich arbeite z.B. regelmäßig mit MySQLTuner und TuningPrimer um meine MySQL Server Einstellungen an die Anzahl der darauf laufenden Seiten und erhöhten Zugriffszahlen anzupassen (etwa alle 1-2 Monate kontrollier und korrigier ich das).


    Hier ein paar Details:
    PHP 5.4
    MySQL5
    Webserver: Apache/2.2.22
    Datenbank-Client Version: libmysql - mysqlnd 5.0.10 - 20111026
    PHP-Erweiterung: mysqli
    phpmyadmin: Versionsinformationen: 4.1.14.8


    Was genau ist APC?
    WIe gesagt ich habe einen Managed-Server. Wüsste nicht das ich mit MySQLTuner oder selbigen arbeiten könnte. MemCacheD sagt mir leider auch nichts.

    Ach mist, Managed - ich hatte Dedicated gelesen.


    APC ist ein opcache, der sorgt dafür das die PHP Script nicht bei jedem Aufruf vom PHP interpreter neu kompiliert werden.
    Er lädt die quasi alle in den Speicher vom OS und holt die immer von da solang die sich nicht verändert haben, das kann - je nach System - 30-50% mehr Performance pro Seitenaufruf bringen (Lektüre: http://de.wikipedia.org/wiki/PHP-Beschleuniger).
    Wenn du eine PHP Live auf dem Server änderst erkennt das APC aber und lädt dann die neue Version (z.B. wenn man Extensions, Joomla oder so updated).


    Ich hab keinen Server ohne APC laufen, dafür ist mir Performance einfach zu wichtig :)


    Das dein PHP 5.4 mysqlnd benutzt ist auch schonmal Top :)


    Ob APC vorhanden ist kannst du im Joomla Backend unter "Systeminformationen" -> PHP sehen, dort einfach mal mit strg+f nach "apc" suchen.

    Dann frag mal bei 1&1 nach ob die dir php-apc aktivieren können oder, besser, PHP5.5 mit apcu.
    Das sollte eigentlich möglich sein.