Beiträge von www.HDsports.at

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.

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

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)

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...

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

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

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

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.

Zitat von deltapapa

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?

Alles anzeigen

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 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