Langsame Webseite seit Umstellung auf 64 Bit

[brettiUN]

Hallo Forum,

gestern Nacht wurde meine Joomlaseite auf die neuen DF-Tarife migriert. Seit dem ist die Seite sehr langsam und wird zum Teil wegen Überlastung von DF gesperrrt. Vorher lief alles über 7 Jahre fehlerfrei.
Sucuri hat die Firewall etwas gegen Bad Bots verändert, was etwas mehr Performance brachte.
Der technische Support meint, dass die PHP-Prozesse eine Schleife verursachen, weshalb Prozesse nicht beendet werden und somit das Limit für die maximale Anzahl von Prozessen erreicht wird.
Dieser Fehler schien vor der Umstellung nicht aufgetaucht zu sein.

Dann wurde mir ein Logfile angehängt, mit dem ich wirklich nichts anfangen kann, auch wenn ich mit Joomla relativ gut umgehen kann.

Die Suche im Internet hat nichts ergeben.

Vielleicht hat jemand einen Tipp,

woran es liegen kann.


Gruß

Armin

Achja, aktuelle Joomlaversion 3.10.11

Hier der Logfile:
0 mysqli_query <internal>:-1
1 JDatabaseDriverMysqli::execute /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/joomla/database/driver/mysqli.php:564
2 JDatabaseDriver::loadObjectList /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/joomla/database/driver.php:1694
3 Joomla\CMS\MVC\Model\BaseDatabaseModel::_getList /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/MVC/Model/BaseDatabaseModel.php:318
4 Joomla\CMS\MVC\Model\ListModel::getItems /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/MVC/Model/ListModel.php:180
5 ContentModelArticles::getItems /kunden/xxxxxxx/webseiten/xxxxxxx/components/com_content/models/articles.php:574
6 ModArticlesLatestHelper::getList /kunden/xxxxxxx/webseiten/xxxxxxx/modules/mod_articles_latest/helper.php:34
7 Joomla\CMS\Helper\ModuleHelper::<main> /kunden/xxxxxxx/webseiten/xxxxxxx/modules/mod_articles_latest/mod_articles_latest.php:1
8 Joomla\CMS\Helper\ModuleHelper::renderModule /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Helper/ModuleHelper.php:141
9 Joomla\CMS\Document\Renderer\Html\ModuleRenderer:: render /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Document/Renderer/Html/ModuleRenderer.php:37
10 ModulesWarpHelper::load /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/warp/systems/joomla/helpers/modules.php:74
11 TemplateWarpHelper::<main> /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/warp/systems/joomla/layouts/modules.php:1
12 TemplateWarpHelper::render /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/warp/helpers/template.php:29
13 ModulesWarpHelper::render /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/warp/systems/joomla/helpers/modules.php:59
14 TemplateWarpHelper::<main> /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/layouts/template.php:1
15 TemplateWarpHelper::render /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/warp/helpers/template.php:29
16 Joomla\CMS\Document\HtmlDocument::<main> /kunden/xxxxxxx/webseiten/xxxxxxx/templates/kamenweb/index.php:1
17 Joomla\CMS\Document\HtmlDocument::_loadTemplate /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Document/HtmlDocument.php:666
18 Joomla\CMS\Document\HtmlDocument::_fetchTemplate /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Document/HtmlDocument.php:709
19 Joomla\CMS\Document\HtmlDocument:arse /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Document/HtmlDocument.php:553
20 Joomla\CMS\Application\CMSApplication::render /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Application/CMSApplication.php:1080
21 Joomla\CMS\Application\SiteApplication::render /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Application/SiteApplication.php:739
22 Joomla\CMS\Application\CMSApplication::execute /kunden/xxxxxxx/webseiten/xxxxxxx/libraries/src/Application/CMSApplication.php:200
23 <main> /kunden/xxxxxxx/webseiten/xxxxxxx/index.php:1
Sowie folgende Query:
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 c.published = 2 AND a.state > 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,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, a.ordering,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,c.published, c.published AS parents_published, c.lft,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,COALESCE(NULLIF(ROUND(v.rating_sum / v.rating_count, 0), 0), 0) AS rating,
COALESCE(NULLIF(v.rating_count, 0), 0) as rating_count
FROM kam_content AS a
LEFT JOIN kam_categories AS c ON c.id = a.catid
LEFT JOIN kam_users AS ua ON ua.id = a.created_by
LEFT JOIN kam_users AS uam ON uam.id = a.modified_by
LEFT JOIN kam_categories as parent ON parent.id = c.parent_id
LEFT JOIN kam_content_rating AS v ON a.id = v.content_id
WHERE a.access IN (1,1) AND c.access IN (1,1) AND c.published = 1 AND a.state = 1 AND (a.catid = 62 OR a.catid IN (
SELECT sub.id
FROM kam_categories as sub
INNER JOIN kam_categories as this ON sub.lft > this.lft AND sub.rgt < this.rgt
WHERE this.id = 62)) AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2022-11-14 14:51:36') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2022-11-14 14:51:36')
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 LIMIT 13 |

[Gast]

Das ist jetzt auch sehr schwer zu bewerten ohne genauere Details? Gibt es hier eine Ticket ID?

Das Thema hatten wir schon. Dummerweise wurde während dessen das Ticketsystem umgestellt, so dass ich sowohl im alten als auch im neuen System Tickets hatte. Aber es gab jeweils keinen Weg mehr, diese aufzurufen. (Und im neuen gingen die E-Mails leider direkt an den Kunden) Daher habe ich alles weitere telefonisch versucht zu klären. Und auch ich habe leider erlebt, dass es am Telefon heisst: wir können da inzwischen leider nichts tun, versuchen Sie es bitte mit der Technik, bitten Sie um Kulanzserverwechsel etc. "Die Technik" kann aber nur per Ticket erreicht werden, die dann wiederum ich nicht mehr einsehen kann etc..
Ach, irgendwie wollte ich nur bestätigen. dass ich auch mit der Aussage konfrontiert wurde, die Website würde auf einmal zu viele PHP Prozesse starten und ich damit und mit der Aufgabe, irgendwie herauszufinden, was das denn verursacht, allein gelassen wurde. Bin hier jetzt auch wieder raus. Projekte, bei denen es auf den technischen Support ankommt, wandern einfach nicht mehr zu df. Die Feld-Wald-und-Wiesen Website, die auch gerne mal ein paar Tage offline sein darf, liegt durchaus aus Bequemlichkeit (E-Mail Umzug) noch hier.

[wecotec]

Vermutung: Mit dem "Upgrade" wurde ja auch die DB von mySQL 5.6 auf MariaDB (oder wars mysql 5.7 ?) umgestellt. Da wird es vielleicht haken.

Das der Fehler in PHP liegt halte ich für ausgeschlossen, da hat sich ja nicht viel verändert.

[Nico]

Hast du da einen Cronjob laufen?

[brettiUN]

Ich habe nur einen Cronjob laufen, der einmal am Tag um 22 Uhr einen Dump von der Datenbank macht. Also nichts ungewöhnliches.

[wecotec]

Ich habe nur einen Cronjob laufen, der einmal am Tag um 22 Uhr einen Dump von der Datenbank macht. Also nichts ungewöhnliches.

Ich würde den trotzdem mal testweise deaktivieren. Und den SQL-Aufruf, der im Log auftaucht, mal händisch nachstellen.

[Nico]

Ich habe nur einen Cronjob laufen, der einmal am Tag um 22 Uhr einen Dump von der Datenbank macht. Also nichts ungewöhnliches.

So etwas "nicht ungewöhnliches" hatte ich auch. In meinem Fall war es ein Cron des Scheduler von Laravel. Seit dem neuen Server muss ich diesen explizit beenden, sonst läuft der nach ein paar Tagen hunderte mal. Auf dem alten Server wurden die Scripte nach Ende der Scriptlaufzeit gekillt. Auf dem neuen Server gibt es dieses Limit nicht mehr.
Ich musste alle PHP Tasks einmal von der Technik killen lassen. Den Cron starte ich seitdem mit Timeout und es flutscht wieder.

[Nils Dornblut]

Hallo brettiUN,

bitte bleiben Sie da mit der Technik in der Analyse. Das ist ohne genaue Sicht auf die Installation schwierig zu beurteilen.

Was nutzen Sie denn an Datenbank- und PHP-Version? Hat die Technik etwas zur Anzahl oder zu den genauen PHP-Prozessen, die das Problem verursachen gesagt?

Mit freundlichen Grüßen

Nils Dornblut

[brettiUN]

Die Technik hat mir zuerst gesagt ich sollle den Überlastungsschutz kaufen. Als ich schrieb, dass der ja nur an drei Tagen das Problem lösen würde, wurde mir nach etwas hin und her die o.g. Logfiles zugespielt, ich solle meinen Webentwickler kontaktieren. Als ich sagte, dass ich es seit 20 Jahren selber bin, wurde mir noch einmal gesagt, dass ich diese Schleifen beenden muss. Danach war für die Technik der Fall erledigt. Auch das Argument, dass auf der Seite so viel Traffic liegt, weil es eine Online-Tageszeitung einer 50000-Einwohner Stadt ist und ich gerne bereit bin, mehr Performance zu buchen, wurde ignoriert. Das war das erste Mal in ca. 16 Jahren DF, dass man mich mit meinem Problem einfach allein gelassen hat.
Der Datenbankdump, der per Cronjob läuft, ist übrigens Ihr Script, was ansonsten sehr gut finde.
PHP ist 7.4 und MySql 7.8. Wie gesagt auf der alten Plattform lief es damit über Jahre fehlerfrei. Dort hatte ich auch die höchste 7er MySql Version und PHP-Version eingestellt.

[Gast]

Ich hatte das gleiche Problem mit einer WP Seite, auf der gerade eine VEranstaltung beworben wurde. Über alle Seiten des Accounts gab es ca. 1.000 Besucher pro Tag. Technik hat mich genauso allein gelassen, Support riet telefonisch zu einem Kulanzserverwechsel. Technik hat das dann abgelöehnt, weil bei ihnen ja alles ok sein. Tarifwechsel hatten wir gemacht, keine Änderung. Erst der Tageserver (für 4 Wochen bis zum Ende der Veranstaltung) brachte eine Lösung. Mein Kunde hat sich dann entschieden, mit dF zukünftig nicht mehr zusammenarbeiten zu wollen, weil gerade im fall eines Problems wie diesem der Hoster gebraucht wird, um das Problem zu lösen.

[brettiUN]

Ich habe wesentlich mehr Besucher pro Tag, was vor der Umstellung nie ein Problem war. DF hat auch über ca. 16-18 Jahren immer sehr gut und schnell geholfen. Leider merke ich seit ca. 3 Jahren, dass man vom first Level Support mehr und mehr mit Floskeln bedient wird und für dumm gehalten wird. Man hat auch ohnmächtig nach so einem Wechsel keine Chance, dass einem geholfen wird, eine Präsenz, die eine ganze Kleinstadt versorgt, wieder online zu bringen. Man landet überall (telefonisch und im OneDone) bei einer "Firewall" die nicht hilft, sondern einen abhält. Dann wird ein Cache von Sucuri heimlich aktiviert, der zur Folge hat, dass neue Meldungen nicht direkt angezeigt werden. Das wird dann einem als Lösung verkauft. Da ich über viele Jahre sehr gute Erfahrungen mit DF gemacht habe, hoffe ich, dass ich nicht diesen Schritt gehen muss. Aber ich schaue mich schon einmal um.

[wecotec]

Ich habe wesentlich mehr Besucher pro Tag, was vor der Umstellung nie ein Problem war. DF hat auch über ca. 16-18 Jahren immer sehr gut und schnell geholfen. Leider merke ich seit ca. 3 Jahren, dass man vom first Level Support mehr und mehr mit Floskeln bedient wird und für dumm gehalten wird. Man hat auch ohnmächtig nach so einem Wechsel keine Chance, dass einem geholfen wird, eine Präsenz, die eine ganze Kleinstadt versorgt, wieder online zu bringen. Man landet überall (telefonisch und im OneDone) bei einer "Firewall" die nicht hilft, sondern einen abhält. Dann wird ein Cache von Sucuri heimlich aktiviert, der zur Folge hat, dass neue Meldungen nicht direkt angezeigt werden. Das wird dann einem als Lösung verkauft. Da ich über viele Jahre sehr gute Erfahrungen mit DF gemacht habe, hoffe ich, dass ich nicht diesen Schritt gehen muss. Aber ich schaue mich schon einmal um.

Meine Erfahrung: Als ich hier frisch Kunde wurde hatte ich am Anfang viele Fragen, die mein persönlicher Berater telefonisch immer schnell beantwortet hat. Irgendwann war der Punkt erreicht, wo die telefonische Erreichbarkeit schwierig wurde. Egal, per Mail ging es wirklich fix. Inzwischen schwankt das ziemlich stark, mal fix, mal recht langsam, auch antwortet öfter mal jemand anderes vom Support. Fazit: Ein persönlicher Berater ist hier ganz okay und kennt meine Macken :-)

Bei meiner DF-Alternative habe ich keinen persönlichen (kostenpflichtigen) Berater. Supportanfragen gehen direkt an den Techniker, das mir sichtbare Team sind ca. 3-4 Leute. Antwortzeit: Wesentlich fixer (<<10 Minuten) als mit PVI bei DF , egal ob per Mail oder telefonisch . Und wenn es hakt geht der Techniker auch mal eben mit mir auf den Server, er als root und ich als admin-User.

Ich würde keinen Umzug mehr scheuen, bei LAMP-Installationen ist sowas fix erledigt. Einziger Haken sind halt immer Email-Konten von Kunden.

[Gast]

Joomla ist ab 3.9.23 mit PHP 8 kompatibel. Joomla 4 auch mit PHP 8.1. Es sind hier einige mehr Requests pro Sekunde möglich: https://kinsta.com/de/blog/php-benchmarks/#joomla-406
Welche PHP Version wird genutzt?

@Benutzername: Privat (bei einen anderen Hoster) betreibe ich WordPress 6 mit PHP 8.1. Läuft wunderbar. Welche PHP läuft hier?

Ansonsten hat ja DF mittlerweise umfassende Tarife. Speziell hier einen größeren WordPress Webhosting Tarif wählen.

[Nils Dornblut]

Die Technik hat mir zuerst gesagt ich sollle den Überlastungsschutz kaufen. Als ich schrieb, dass der ja nur an drei Tagen das Problem lösen würde, wurde mir nach etwas hin und her die o.g. Logfiles zugespielt, ich solle meinen Webentwickler kontaktieren. Als ich sagte, dass ich es seit 20 Jahren selber bin, wurde mir noch einmal gesagt, dass ich diese Schleifen beenden muss. Danach war für die Technik der Fall erledigt. Auch das Argument, dass auf der Seite so viel Traffic liegt, weil es eine Online-Tageszeitung einer 50000-Einwohner Stadt ist und ich gerne bereit bin, mehr Performance zu buchen, wurde ignoriert. Das war das erste Mal in ca. 16 Jahren DF, dass man mich mit meinem Problem einfach allein gelassen hat.
Der Datenbankdump, der per Cronjob läuft, ist übrigens Ihr Script, was ansonsten sehr gut finde.
PHP ist 7.4 und MySql 7.8. Wie gesagt auf der alten Plattform lief es damit über Jahre fehlerfrei. Dort hatte ich auch die höchste 7er MySql Version und PHP-Version eingestellt.

Ich bitte erst einmal für die Unannehmlichkeiten um Entschuldigung! Gibt es denn ein Ticket dazu, was ich zur Prüfung geben könnte? So ist das leider nur sehr schwer abzuschätzen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ich hatte das gleiche Problem mit einer WP Seite, auf der gerade eine VEranstaltung beworben wurde. Über alle Seiten des Accounts gab es ca. 1.000 Besucher pro Tag. Technik hat mich genauso allein gelassen, Support riet telefonisch zu einem Kulanzserverwechsel. Technik hat das dann abgelöehnt, weil bei ihnen ja alles ok sein. Tarifwechsel hatten wir gemacht, keine Änderung. Erst der Tageserver (für 4 Wochen bis zum Ende der Veranstaltung) brachte eine Lösung. Mein Kunde hat sich dann entschieden, mit dF zukünftig nicht mehr zusammenarbeiten zu wollen, weil gerade im fall eines Problems wie diesem der Hoster gebraucht wird, um das Problem zu lösen.

Das ist jetzt auch sehr schwer zu bewerten ohne genauere Details? Gibt es hier eine Ticket ID?

Mit freundlichen Grüßen

Nils Dornblut

[brettiUN]

Ich bitte erst einmal für die Unannehmlichkeiten um Entschuldigung! Gibt es denn ein Ticket dazu, was ich zur Prüfung geben könnte? So ist das leider nur sehr schwer abzuschätzen.

Mit freundlichen Grüßen

Nils Dornblut

Hallo Herr Dornblut,

in Tickert DF-67673 habe ich vor der Migration auf ein mögliches Problem mit Sucuri hingewiesen und bin dort trotz erneuter Nachfrage beruhigt worden. Es kam wie befürchtet dazu, dass nach der Migration die Seite bis morgens zu meinem Eingreifen offline war.

Das Ticket DF-72671 bearbeitet das Geschwindigkeitsproblem. Allerdings gab es auch noch Telefonkontakt und E-Mails aus der Technik, die hier in diesem Ticket nicht aufgeführt wurden. Beim Telefonkontakt endete die Warteschleife in einer asiatisch klingenden Warteschleife mit anschließendem Trennen der Verbindung. Geschätzte Wartezeit nach erstem Telefonkontakt ca. 1 Stunde und dann noch einmal mit einem Mitarbeiter, der uns sagte, dass er uns verstehen können, aber nicht helfen kann. Wir sollten es weiter mit der Technik versuchen.

Ticket DF-72925 wurde bis heute nicht beantwortet.