Xenforo 2.3 schneller als 2.2 !?

[Masetrix]

So wurde das zumindest suggeriert. Meinen unprofessionellen Test nach aber ist das scheinbar nicht der Fall.
Auch Pagespeed sagt etwas anderes.
Xenforo aktuell 2.3:

 

[Masetrix]

Dem gegenüber ein aktuelles XenForo 2.2



Hat jemand mehr zu XF 2.3 in Sachen "Speed" ?

 

[Masetrix]

Sorry, zurück....

Ich habe da offensichtlich Äpfel und Birnen verglichen.
Beim Test von XF 2.2 und 2.3 mit dem gleichen Server und Inhalten kommt dann das heraus und XF 2.3 ist definitiv schneller..

 

[Maestro2k5]

Standard Installation ohne alles?

 

[Masetrix]

Standard Installation ohne alles?

Meinst du mich=
Dann nein, 2 identische Foren, einmal öffentlich, auf XF 2.2 und alles nochmal intern zum Testen, nun auf XF 2.3 B3 upgedatet und dann getestet. Siehe oben die Ergebnisse

 

[Maestro2k5]

Unsere Postings hatten sich wohl überschnitten.

 

[Kirby]

2.3 muss unter gleichen Voraussetzungen im Hinblick auf die Client-Performance eigentlich (deutlich) schneller sein als 2.2:

• Kein Render Blocking mehr für Fonts => verbessert FCP
• Mit HTTP/2+: Modulareres CSS, dadurch bessere Cache Granlularität und ggf. weniger zu parsen => verbessert FCP
• Kein jQuery mehr, somit weniger JS Payload und schnellere Ausführung da Native => verbessert FID/INP
• Modulareres JavaScript und Lazy Execution von Handlern => verbesert FID/INP
• Early Discovery aber Deferred Execution von JavaScript => verbesert FID/INP
• Größenangaben für IMG & IFrame => verbessert CLS
• WebP => kleinere Bilder => verbessert FCP
• Etliche Dinge sind jetzt Native anstatt JS (Sticky, Date Picker, etc.)

 

[Masetrix]

2.3 muss unter gleichen Voraussetzungen im Hinblick auf die Client-Performance eigentlich (deutlich) schneller sein als 2.2:

• Kein Render Blocking mehr für Fonts => verbessert FCP
• Mit HTTP/2+: Modulareres CSS, dadurch bessere Cache Granlularität und ggf. weniger zu parsen => verbessert FCP
• Kein jQuery mehr, somit weniger JS Payload und schnellere Ausführung da Native => verbessert FID/INP
• Modulareres JavaScript und Lazy Execution von Handlern => verbesert FID/INP
• Early Discovery aber Deferred Execution von JavaScript => verbesert FID/INP
• Größenangaben für IMG & IFrame => verbessert CLS
• WebP => kleinere Bilder => verbessert FCP
• Etliche Dinge sind jetzt Native anstatt JS (Sticky, Date Picker, etc.)

Ich schlage mich bei der 2.3 noch immer durch gewisse "Unwägbarkeiten" in Sachen einer Testinstallation, die der LiveSite in allen Dingen möglichst nahe kommt. Immerhin erspart mir der Importer eine Menge von der Kopierarbeit die ich mir zuerst immer antat.Dann mache ich erneut SpeedTests und werde hier berichten.

 

[otto]

Dumme Frage:
Du importierst statt zu upgraden? Wenn ja, warum? Oder hab ich das nu falsch heraus gelesen?

 

[Kirby]

Dumme Frage:
Du importierst statt zu upgraden? Wenn ja, warum? Oder hab ich das nu falsch heraus gelesen?

Das würde mich auch interessieren, gibt für mich irgendwie 0 Sinn:
Ein Import dauert prinzipbedingt immer (sehr viel) länger als ein simpler Klon (Dateien kopieren, Dump der DB erstellen und in neue DB importieren, Config anpassen - fertig) und man verliert ggf. Daten.

Das Update eines Klons auf einen neuen Stand des Produktiv-Systems geht sogar noch einfacher / schneller:
rsync der Dateien, Dump der Produktiv-DB und Import desselben in Klon-DB - fertig.

 

[Masetrix]

Dumme Frage:
Du importierst statt zu upgraden? Wenn ja, warum? Oder hab ich das nu falsch heraus gelesen?

Ja. ich importiere zuerst die Daten, die sich in der LiveSite inzwischen, zur Testsite geändert haben, sodass Testinstallation und LiveSite die gleichen Daten aufweisen.
Dann wird die Testseite gesichert (Backup), dann erfolgt dort ein Upgrade auf 2.3.x.
Den Umweg würde ich mir gerne ersparen und direkt von 2.2 in die 2.3 importieren, da gibt es aber noch keine 2.3 Option für den Import.

 

[Masetrix]

Das würde mich auch interessieren, gibt für mich irgendwie 0 Sinn:
Ein Import dauert prinzipbedingt immer (sehr viel) länger als ein simpler Klon (Dateien kopieren, Dump der DB erstellen und in neue DB importieren, Config anpassen - fertig) und man verliert ggf. Daten.

Das Update eines Klons auf einen neuen Stand des Produktiv-Systems geht sogar noch einfacher / schneller:
rsync der Dateien, Dump der Produktiv-DB und Import desselben in Klon-DB - fertig.

Clonen etc. ist mit zu viel Aufwand bei persönlichem Zutun verbunden, der Import per Importer, also eine Synchronisierung 2-2->2.2 dauert vielleicht länger, läuft aber, wenn einmal gestartet, ohne mein Zutun ab. Das kann gerne einen Arbeitstag lang dauern.

Ok, einen Nachteil hat das auch, denn der Importer überschreibt nicht die "alten" Daten z.B. in der xf_post-tabelle, er hängt nur neu an, aber da das nur temporär genutzt und hernach wieder gelöscht wird, nehme ich den eigentlich sinnlos verdoppelte Bedarf an Platz in der DB, in Kauf.