Webseite brutal langsam

Auf php 5.5. kann ich selbst umstellen. Habe es mich bisher aber nicht getraut, da bei 1und1 folgender Hinweis stand:
Diese PHP-Version unterstützt noch nicht alle Anwendungen.
Allerdins scheint alles gut zu laufen, nachdem ich jetzt umgestellt habe.

Bezgl. APCu werde ich nachfragen.

Kann mir jemand noch bzgl. Server-Einstellungen behilflich sein, ob man da hinsichtlich Joomla etwas optimieren kann.
WebDav: an/aus (eingestellt ist an)
FastCGI: an/aus (Eingestellt ist aus)
SSLSupport: an/aus (Eingestellt ist an)
Einbindung von Perl als: Modul/CGI (EIngestelt ist CGI)
Einbindung von PHP al: Modul/CGI (Eingestellt ist Modul; bis vor Kurzem war CGI eingestellt)
Speichernutzung: 524288 kB (hatte ich vor Kurzem erhöht)
Prozesslaufzeit: 360 Sekunden
Anzahl gleichzeitig ausführbarer Prozesse: 100
Diese Einstellungen kann ich alle verändern

Jetzt verwirrt ihr mich aber
b2un0 sagt "hp als Apache-Modul ist schneller" und flotte wiederum es soll nicht als Modul laufen.

Was ist denn nun richtig?

ist wieder umgestellt.
macht eigentlich keinen Unterschied.
So oder so bleibt die Zeit bis zum ersten Connect über eine Sekunde, was ziemlich schwach ist...

Ich habe jedoch nur Einbindung von PHP als auf CGI umgestellt

Muss ich FastCGI auch noch aktivieren?

Jetzt taucht plötzlich die Fehlermeldung auf meiner Seite auf:
CGI-limits reached, please try again later!

Das Problem mit der langen Wartezeit beim Speichern ist auch doch nicht gelöst.
Die langen Wartezeiten sind schon wieder da

Zum Kotzen

ich habe mittlerweile meine Seite auch localhost laufen und auch das gleiche Problem mit der langen Wartezeit für First Connect. Also der Hoster ist sicher nicht schuld - das kann mal mal ausschließen.

Zudem hat mir der Hoster eine slowmysql.log geschickt. Dort fiel mir auf das massenhaft dieser Abfragen liefen.

# Time: 150408 19:35:15
# User@Host: dbo376405720[dbo376405720] @ localhost []
# Query_time: 2.358831  Lock_time: 0.000273 Rows_sent: 5293  Rows_examined: 174411
SET timestamp=1428514515;
SELECT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.language,  LENGTH(a.fulltext) AS readmore,CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published
FROM ngie_content AS a
LEFT JOIN ngie_content_frontpage AS fp ON fp.content_id = a.id
LEFT JOIN ngie_categories AS c ON c.id = a.catid
LEFT JOIN ngie_users AS ua ON ua.id = a.created_by
LEFT JOIN ngie_users AS uam ON uam.id = a.modified_by
LEFT JOIN ngie_categories as parent ON parent.id = c.parent_id
LEFT JOIN ngie_content_rating AS v ON a.id = v.content_id
LEFT OUTER JOIN (SELECT cat.id as id FROM ngie_categories AS cat JOIN ngie_categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.published != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id
WHERE a.access IN (1,1,5) AND c.access IN (1,1,5) AND CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2015-04-08 17:35:12') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2015-04-08 17:35:12')
ORDER BY  c.lft,   CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END  DESC ,  a.created;

Was mir ins Auge sticht, ist "Rows_Sent 5293". Das scheint mir ein unglaublich hoher Wert.
Und wenn dann solche Prozesse fast jede Sekunde laufen bzw. wahrscheinlich immer dann wenn auf meiner Seite eine Page mit Artikelinhalt aufgerufen wird, wundert es mich nicht wenn ich einen Netzwerkverkehr von 3-4 GiB pro Stunde (!!) habe und das führt wohl in der Folge zur langen Wartezeit auf den "First Connect"

Wie ich diese Prozesse unterbinde ist mir leider noch nicht gelungen. Über Rat würde ich mich freuen. Vielleicht kann ja jemand diese SQL-Prozesse besser interpretieren...

Hey, nein das Problem wurde leider nicht gelöst. Performance ist noch immer miserabel...

Servus Jan,
danke für deinen Rat

ich hatte mich über ein halbes Jahr lang bemüht das Problem zu lösen, allerdings ohne einem einzigen Lichtblick.
Deine Lösungsvorschläge hatte ich im Großen und Ganzen alle schon durchprobiert, Standard-Template, alle externen Module, Plugins und Komponenten ausschalten usw. ohne Erfolg.

Hatte auf meinen Server eine neue Joomla-Seite angelegt und nur die Beiträge und Kategorien importiert und dann dann hatte ich beim SPeichern eines neuen Artikel in einer Kategorie mit vielen existierenden Artikeln erneut eine Wartezeit von 2 Minuten bis gespeichert wurde.
Dann legte ich auf einem Hoster, wo man kostenlos Webspace bekommt, erneut eine JOomla-Seite an und exportierte die Artikeln und Kategorien und siehe da, keine Wartezeit. Also liegt möglicherweise Nahe das der Server gehackt wurde oder irgendwo im Webspace meiner Seite ein File liegt, das diese Performance Probleme auslöst.
Und das mit der langen Wartezeit beim Speichern ist ja nicht das einzige Problem (http://forum.joomla.org/viewtopic.php?f=710&t=863245 oder http://forum.joomla.org/viewtopic.php?f=709&t=882234)

Um des Rätsels Lösung aber eventuell tatächlich finden zu können, müsste ich wieder hunderte Stunden dasitzen, und das ist mir mittelweile meine Zeit nicht wert. Ich möchte gar nicht wissen wie viele Stunden und Nächte ich mich schon diesem Problem gewidmet hatte.

Wenn du Lust hast, kann ich dir gerne Zugangsdaten zum Backend senden, vielleicht hast du ja mehr Glück wie ich...

LG Tom

Zitat von addi

Nichts geht ohne ordentliche Ursachenanalyse, da kannste dich noch so viel im Kreis drehen.

Als Notlösung könnte man einen 404 senden, wenn kein Artikel-Limit oder ein zu hohes Artikel-Limit über die Joomla-URL erfragt wird. Zur Not sollte eine ip-Blockierung helfen. Bei einem solchen Fall sollte man einen Profi ran lassen.

Glaub mir habe ich schon genug gemacht. Bzgl. der langen Wartezeit beim SPeichern eines Artikel bin ich aber mittlerweile längst mit meinem Latein am Ende.
Hatte 100 Artikel einer Kategorie mittels J2xml exportiert und diese dann local auf einer leeren Joomla-Seite mittels J2xml in eine leere Kategorie importiert. Und auch da hatte ich nach dem Speichern eines neuen Artikels in der Kategorie mit den 100 existierenden Artikeln eine längere Wartezeit aufgrund der Ordering-Prozesse...

Im Anhang habe ich eine .gz-Datei hochgeladen, die 100 Artikel enthält. Lade ich die mittels J2XML in die leere Joomla-Seite in eine Kategorie, habe ich beim Speichern eines neuen Artikels in derselben Kategorie eine längere Wartezeit... (könnt ihr gerne selbst testen)..

Zitat von Pest

Hallo Tom

Mit einem Zugang zum FTP (Seite und Logdateien) könnte ich schauen ob dort eventuell Schadcode hinterlegt wurde der nun zu diesem Problemen führt. Bei einem Kunden hatten wir beispielsweise Abfragen zu einem Wordpress drin, die beim vorhandenen Joomla natürlich nicht funktionieren konnten, aber für einen stark verzögerten Seitenaufbau gesorgt haben. Das wäre jetzt noch so eine Idee die bei deinem Problem "passen" könnte.

Grundsätzlich müsste dann aber eigentlich auch deine Kopie bei einem anderen Anbieter langsam laufen, da diese fehlerhaften Anfragen an die Datenbank mit übernommen worden wären.

Gruß Jan

Alles anzeigen

Hallo Jan. Falls dein Vorschlag noch aktuell ist, schreib mir bitte eine PM.

Sorry für den Doppelpost.
Aber zum mysteriösem Problem mit der langen Wartezeit beim Speichern eines Artikels, konnte ich den möglichen Ursachenbereich deutlich eindämmen.

Folgendes habe ich getan:
100 Artikel von meiner bestehenden Joomla-Seite mittels j2xml exportiert.

In Xampp und bei einem Gratis-Hoster (bplaced) eine leere Joomla-Seite angelegt
Auf beidem (Xampp/Bplaced) J2xml installiert und die 100 Artikel mit den Standard-Einstellungen importiert (alle Artikel stammen von ein und derselben Kategorie)
Dann auf beiden Plattformen einen neuen Artikel in der Kategorie mit den 100 existierenden Artikeln gespeichert.
Das Ergebnis: Speichervorgang beim Speichern des Artikels war bei Xampp wieder lange (im Status von phpmyadmin fielen mir wieder die bekannten Ordering-Prozesse auf). Speichervorgang bei bplaced hingegen blitzschnell.

Somit kann das Problem also nur durch irgendwelche Server- oder Datenbankkonfigurationen entstehe? bin aber etwas verwundert, wieso von so einem Problem noch nie berichtet wurde. Denke mal, das ich nicht der einzige bin der Xampp benutzt. Dann müsste das Problem ja auch bei anderen Xampp-Usern auftreten - bis auf ein paar Änderungen in der php.ini habe ich bei xampp nichts angepasst (aber auch mit der Standard php.ini ändert sich nichts am Problem)... Leider konnte ich bis dato noch nicht eruieren an was es genau liegt, beim Vergleichen der beiden Datenbanken ist mir zumindest auf dem ersten Blick keine Unstimmigkeit aufgefallen...

Zitat von breaky

Hi,
ich habe genau das gleiche Problem. Ich betreibe ca. 50 Joomla Seiten und habe das Problem bei genau 1. Bei mir läuft das auf einem managed Server auch bei 1&1.
Das ist die umfangreichste Seite mit ca 6000 Artikeln und 20000 Fotos. Die DB ist Optmiert und aufgeräumt 45 MB groß.
Ich dachte mit PHP7, mySQL 5.5 und Joomla 3.5 wird es besser. Leider ist dem nicht so.
Für konstruktive Lösungsansätze bin ich sehr offen

Hey,
ich habe mich von 1und1 verabschiedet und bin zu einem anderen Hoster gewechselt. Und siehe da, die Performance war deutlich besser. TimeToFirstByte hat sich halbiert und sonst läuft die Seite auch flüssiger. Das in meinem vorangegangen Post beschriebene Problem mit der langen Wartezeit beim Speichern von neuen Beiträgen habe ich auch nicht mehr (wobei ich trotzdem verwundert bin, das das Problem sogar mit Xampp auftritt...)
Liegt also meiner Meinung nach an 1und1