Performace

    Hallo Jan,
    ich arbeite sehr intensiv mit Custom Fields (125 Stck).
    Da machen Deine Aussagen Sinn und je mehr Datensätze es werden desto "schlimmer" wird es vermutlich.
    Würde ein "Aufbohren" des Datenbankservers Sinn machen?

    Hallo Christine,
    das hat Joomla selber vorgeschlagen, dabei waren wir schon über 900 Tage.

    Also bei den Modulen wäre es durchwegs schön, wenn man die parametrisieren könnte und nich für jeden Fall ein Eigenes machen müßte.
    Müsste auch Theoretisch gehen, nur eine Frage des Programmieraufwand und ob man nicht bei jedem Update wieder alles neu machen müsste.

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von Micki mit diesem Beitrag zusammengefügt.

    Wie muss ich deine Aussage verstehen?

    Auf einer Seite werden bei jedem Seitenaufruf 500 Module abgearbeitet?

    Die zugängliche J3 ist schon sehr langsam im Aufbau. Hast du mal den Seitenaufbau mit den EWebentwicklertools untersucht, wo die langen Ladzeiten herrühren.

    Ich gehe nicht davon aus, dass dies mit der Artikelanzahl an sich zu tun hat.

    Zitat von Micki

    Würde ein "Aufbohren" des Datenbankservers Sinn machen?

    Die echten Werte wirst Du erst im produktiven Betrieb sehen. Ein angemessenes Hosting welches sich nach der Größe des Projekts richtet, sollte wohl selbstverständlich sein. Joomla.org auf einem 5-Euro-Shared-Hosting würde auch abschmieren. Generell kannst Du schon viel mit der Verwendung des Cache regeln. Der fängt die immer wiederkehrenden Datenbankabfragen ab und nimmt sich in der erweiterten Fassung auch die Module vor. Hast Du Zeit und Lust kannst Du hier auch einen Redis einbinden und Dein Joomla noch weiter entlasten. Bieten aber nicht alle Hoster an und der Redis muss separat konfiguriert werden.


    Läuft das Projekt aber schon mit z.B. 500 Beiträgen in einer Testumgebung ohne Traffik langsam, hast Du wahrscheinlich ein strukturelles Problem oder der Server trägt zu viel Grundlast.

    Zitat von Lui_brempt

    Wie muss ich deine Aussage verstehen?

    Auf einer Seite werden bei jedem Seitenaufruf 500 Module abgearbeitet?

    Die zugängliche J3 ist schon sehr langsam im Aufbau. Hast du mal den Seitenaufbau mit den EWebentwicklertools untersucht, wo die langen Ladzeiten herrühren.

    Ich gehe nicht davon aus, dass dies mit der Artikelanzahl an sich zu tun hat.

    1. Es werden nicht 500 Module beim Steitenaufruf abgearbeitet. Hoff ich zumindest.
    2. Es war gfragt wo denn die Migrationsprobleme seien.
    3. Ein Seitenaufruf denk ich macht so um die 10 - 15 Module

    4. Es kommen sehr viele customfilds zum einsatz, vermutlich "zu viele".

    Zitat von Pest

    Die echten Werte wirst Du erst im produktiven Betrieb sehen. Ein angemessenes Hosting welches sich nach der Größe des Projekts richtet, sollte wohl selbstverständlich sein. Joomla.org auf einem 5-Euro-Shared-Hosting würde auch abschmieren. Generell kannst Du schon viel mit der Verwendung des Cache regeln. Der fängt die immer wiederkehrenden Datenbankabfragen ab und nimmt sich in der erweiterten Fassung auch die Module vor. Hast Du Zeit und Lust kannst Du hier auch einen Redis einbinden und Dein Joomla noch weiter entlasten. Bieten aber nicht alle Hoster an und der Redis muss separat konfiguriert werden.


    Läuft das Projekt aber schon mit z.B. 500 Beiträgen in einer Testumgebung ohne Traffik langsam, hast Du wahrscheinlich ein strukturelles Problem oder der Server trägt zu viel Grundlast.

    Momentan läuft live und test/Migration auf dem selben Server, das heißt man muss letztlich migrieren das alte abschalten und schauen was passiert. Dann kann man weitere Maßnahmen überlegen.

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von Micki mit diesem Beitrag zusammengefügt.

    Seite ist Offline!?

    Kann ich nicht analysiern.


    Artikel, Kategorien etc. könntest du hiermit migrieren:



    J2XML 3.9
    J2XML 3.9 is the ultimate solution for sharing your content between Joomla! 3 and Joomla! 4
    www.eshiol.it




    Ist zwar eine Betaversion, aber du kannst die Inhalte übertragen und dann die Erweiterung wieder löschen:

    Zitat von Re:Later

    Ich habe jetzt mal alles überflogen und verstehe immer noch nicht über welche "Performance-Probleme" hier eigentlich geredet wird.

    Zitat von christine2

    Zu Deinem Link (Seite) in #17: Da müssen wir jetzt 880 Tage warten? :)


    Micki hat Performance Probleme auf seiner Joomla 4 Webseite die in 880 Tagen online ist. Bis dahin müssen wir uns gedulden um die Seite analysieren zu können.

    Zitat von Stef

    Micki hat Performance Probleme auf seiner Joomla 4 Webseite die in 880 Tagen online ist. Bis dahin müssen wir uns gedulden um die Seite analysieren zu können.

    Hallo Stef!

    Hier kamen ja schon wirklich auch brauchbare Hinweise! z. B. von Pest, dem ich hiermit noch einmal danke! Die Haupterkenntnis ist leider die dass Joomla verm. für mein Projekt die "falsche" Software ist. Wobei momentan nichts anderes über bleibt als erst mal migrieren um dann in Ruhe nach einer Alternative zu suchen!

    Zitat von Micki

    ...Die Haupterkenntnis ist leider die dass Joomla verm. für mein Projekt die "falsche" Software ist. Wobei momentan nichts anderes über bleibt als erst mal migrieren um dann in Ruhe nach einer Alternative zu suchen!


    Micki , ist doch Zeitverschwendung, wenn du dann alles nochmals auf einer anderen Software migrieren willst.

    Zitat von Stef

    Micki , ist doch Zeitverschwendung, wenn du dann alles nochmals auf einer anderen Software migrieren willst.

    Ist es theoretisch! Aber ich hab diese Erkenntnis ca. 8 h und in der Zeitspanne findet sich leider kein Ersatz. Der sollte sich nämlich dazu eignen nicht nach 2-3 Jahren wieder einen Komplettumzug machen zu müssen.
    Aus Erfahrung weiß ich, dass sich so was leider über Monate hinziehen kann und am 28.11. ist PHP 7 deadline.

    Zitat von Stef

    Micki hat Performance Probleme auf seiner Joomla 4 Webseite die in 880 Tagen online ist. Bis dahin müssen wir uns gedulden um die Seite analysieren zu können.

    Ja, aber welche denn eigentlich? Wie äußern sich die denn? Was sieht man denn, was einen vermuten lässt...? Oben wird was über Joomla 4 gesagt und ob man sein Geld für größere Server ausgeben soll etc. pp. Oder geht's hier um rein hypothetische und/oder gefühlte Performance-Probleme, denen ja viel zu viele hinterherjagen? So meinte ich das... Egal.

    Also zum besseren Verständnis:

    1 Webspace auf dem läuft zum einen die Liveversion http://www.knabenchorarchiv.org dies hat schon seit längerem leichte Performanceprobleme. Ich hatte schon vermutet, dass das von den Customfields kommen könnte (Hypothese). Auf dem Webspace besindet sich ebenfalls die 4.0 Testversion. Sollte das migrieren einfacher machen. Hoster meinte nach den Performensproblemursachen erst suchen, wenn die neue Version produktiv und die alte abgeschalten. Plausiebel, man muss ich ja die Arbeit nicht 2x machen. Wärend der jetzt laufenden Migration, hat die Performance des neuen Backends auch deutlich abgenommen, vom Frontend der Liveversion gar nicht zu reden. Jetzt steht im Raum das Probleme mit dem Frontend der neuen Version auch zu erwarten sind, wenn die Migration voll durch ist. Dann zu der allgemein bemängelten offline anzeige, das hat 3 Gründe Google, das nicht gehen von Links und ich wollte erst mal ohne Besucherstreß die Migration durchziehen.

    Performanceprobleme ist freundlich ausgedrückt. Gefühlt 10 Sekunden dauerte gerade der Seitenauffruf.

    Hast du mal ein Backup der Seite gamacht lokal oder auf anderem Webspace installiert und geschaut, wie dort das Verhalten ist.

    Ich glaube nicht, dass das Performanceproblem an Joomla an sich liegt.

    Von wie vielen Custom-Fields, die bei einem Seitenaufruf verabeitet werden müssen reden wir denn?

    Was sagen die Webentwicklertools bzgl. der Dauer der DB-Anfragen beim Seitenaufruf?

    Zitat von Lui_brempt

    Performanceprobleme ist freundlich ausgedrückt. Gefühlt 10 Sekunden dauerte gerade der Seitenauffruf.

    Hast du mal ein Backup der Seite gamacht lokal oder auf anderem Webspace installiert und geschaut, wie dort das Verhalten ist.

    Ich glaube nicht, dass das Performanceproblem an Joomla an sich liegt.

    Von wie vielen Custom-Fields, die bei einem Seitenaufruf verabeitet werden müssen reden wir denn?

    Was sagen die Webentwicklertools bzgl. der Dauer der DB-Anfragen beim Seitenaufruf?

    Nein ein erster Versuch es gestern Abend auf XAMP mal zu installieren ist gescheitert.
    Customfields da habe ich ca. 120 angelegt aber sind nicht immer alle bei jedem Seitenaufruf dabei, jedoch der Konzertkalender!
    Zu letzterm kann ich noch nix sagen.

    Moin


    Zuerst einmal würde ich alles entfernen das aus externen Quellen geladen wird. So lange die Seite auf die Daten fremder Quellen warten muss, bekommen wir wahrscheinlich keine echten Werte geliefert.


    Code
    https://piwik.phrixos-it.de/piwik.js
https://www.gstatic.com
https://liberapay.com


    Dann sind auf der Seite 26 (!) Javascripte bei insgesamt 33 Anfragen. Entweder ist das ein Grab suboptimal zusammengestellter Erweiterungen / Plugins, oder ein Entwickler hat jedes Problem mit einem Script zu lösen versucht. Da muss mal so richtig ausgemistet werden. ;)


    Vollständige Sicherung des Projekts und dann alle Komponenten und Plugins die zusätzlich installiert wurden, aber nicht aktiv genutzt, komplett deinstallieren. Nicht nur deaktivieren, sondern wirklich komplett runter. Template könnte man testweise auch einmal umschalten um Inkompatibilitäten aus dem Weg zu räumen. Und bitte schauen welche Dateien (JS / CSS) diese riesigen Leerräume in den Quelltext bringen lassen.


    Ein lokaler Test auf XAMPP wird Dir nicht viel bringen, weil diese Umgebung weit entfernt von realen Bedingungen ist. Du bekommst das Geschehen damit in keinen Kontext gesetzt. Du brauchst einen Ausgangspunkt der garantiert sauber konfiguriert und performant ist. In schwierigen Fällen ziehe ich Projekte auf eine Subdomain in mein eigenes Paket und lasse die Tests dort laufen. Außerdem habe ich dann mehr Möglichkeiten für die Fehlersuche, komme selbst an alle relevanten Log-Dateien usw.


    Kurz gesagt, Du solltest sicherstellen das die Basis sauber läuft bevor Du Dich intensiver an die Fehlersuche machst.

    Die letzten Tage ist hier im Forum echt viel Rätselraten agesagt. damit man dir helfen kann:

    - Schalte deine Developmentseite online oder gibt uns hier einen Login um es sich anschauen zu können

    - Nutze die Browser-Konsole um lange Ladezeiten (Netzwerkanalyse) zu erkennen (auf der normalen Seite sind mitnichten die JS/CSS Assets ein Problem, es ist etwas was auf dem Server passiert => siehe ersten Punkt um es auf der Developerseite zu verifizieren)

    - Schalte den Debug Modus deiner Dev-Seite an (Globale Konfiguration + im Debug Plugin), dort siehst du z.b. die Aufrufdauer von langsamen Datenbankabfragen um den Fehler einzugrenzen.


    Alles andere ist (scheinbar mein Lieblingswort): Rätselraten.


    Ob du das Online oder Local auf XAMPP machst ist eigentlich irrelevant, auf Xampp dürfte es einfach nur noch langsamer werden, was ja ok ist um den Flaschenhals einfacher zu erkennen. Wenn du dann den Übeltäter (oder die Übeltäter) gefunden hast, gehts ans optimieren.