Performance Optimierungen

Heute haben wir erneut Performance-Optimierungen auf unserer Plattform vorgenommen, um ein noch besseres Benutzererlebnis zu gewährleisten. Uns ist es besonders wichtig, dass unsere Besucher sich schnell und intuitiv zurechtfinden und mit wenigen Klicks die gewünschten Informationen erreichen. Jede Sekunde zählt, und wir möchten sicherstellen, dass unsere Seite sowohl schnell lädt als auch effizient navigierbar ist – egal, ob du am Smartphone, Tablet oder Desktop unterwegs bist. Dein Feedback hilft uns, stetig besser zu werden! :rocket:

Im Verlauf des Tages boosten wir die Performance unserer Plattform noch einmal deutlich :rocket:.

Wir arbeiten derzeit an der Implementierung einer ISR-Lösung (Incremental Static Regeneration), um dynamische Inhalte effizienter und schneller auszuliefern. Vorab mussten wir jedoch sicherstellen, dass unser lokales Cache-System ausfallsicher ist. Dafür haben wir unseren Redis-Cluster durch Sentinel erweitert. :floppy_disk::zap:

Warum Sentinel?

Stellen wir uns vor, unser Cluster besteht aus 3 Redis-Servern:

  • Einer fungiert als Master (aktuelle Schreibinstanz).
  • Zwei weitere fungieren als Slaves (Replikationen für Leseoperationen).

Sentinel überwacht die Cluster-Instanzen. Sollte der Master-Server ausfallen, übernimmt automatisch einer der Slaves die Rolle des Masters – ohne Ausfallzeiten für die Plattform. Diese Architektur sichert nicht nur die Verfügbarkeit, sondern verbessert auch die Performance bei Datenbankzugriffen.

Vorteile für euch:

  • Bessere Skalierbarkeit: Dynamische Inhalte können effizient aktualisiert werden.
  • Höhere Ausfallsicherheit: Selbst bei Serverausfällen bleibt das System stabil.
  • Schnellere Ladezeiten: Dank Caching und intelligenter Datenverteilung.

Mehrere Cache-Layer für maximale Performance

Somit bietet 6love ein mehrstufiges Cache-System:

  • Lokal in der API/Middleware: Schneller Zugriff durch ausfallsichere Redis-Server mit Sentinel, optimiert für REST-API-Caches und Middleware-Logik. Inklusive Low-Level-Cache für Lustmap und Sexmap.
  • Lokal in der Infrastruktur: Schneller Zugriff durch ausfallsichere Redis-Server mit Sentinel, um interne Daten schnell bereitzustellen.
  • CDN-Layer: Inhalte werden über unser Content Delivery Network weltweit effizient verteilt.
  • Browser-Cache: Euer Browser speichert häufig genutzte Inhalte lokal, um die Ladezeiten weiter zu minimieren.

Diese Kombination sorgt für eine optimale Nutzererfahrung – schnell, zuverlässig und jederzeit verfügbar. :globe_with_meridians::rocket:

Erste Tests sehen vielversprechend aus.

Wir halten euch über die Fortschritte auf dem Laufenden – bleibt gespannt! :tada:

zwischen 17.11.2024 03:00 - 04:00 kann es ggf. zu einem Unterbruch der Dienste kommen. Wir wollen ein Failover test durchführen.

Failover test bestanden. Sowhl DB Cluster und auch Cache Cluster verkraften 1 Ausfall.

Letzter Test war um 13:30. Ram Verbrauch ist aber extrem gestiegen. Wir müssen das heute genau anschauen. hab mal 24GB Pro VM gehauen.

@evy häsch gseh gha - wenn user registrierig chond gits 2x mal en Signal Event. Ha notifications bereinigt.

ja has grad fixed. bi die nöchschti patches am vorbereite. :sunglasses:

1 „Gefällt mir“

Aktuelle Pendenzen:

Cache-Invaliderung, wenn ein neues Objekt erstellt wird, vor allem bei:

  • Profile → Erstellen und Aktualisieren
  • Ad → Erstellen und Aktualisieren
  • Banner → Erstellen und Aktualisieren
  • Locations → Erstellen und Aktualisieren

Was heißt das? Wenn wir Low-Level-Caching über längere Zeit betreiben, aber in dieser Zeit eine Änderung bei einem Objekt XY stattfindet, muss der Cache natürlich erneuert werden. Sonst würde man veraltete Daten sehen, die nicht mehr aktuell sind.

Diese Thematik ist neu dazu gekommen weil wir eine zusätzliche Cache ebene aufgeschaltet haben.

Wir cachen, damit die App schnell aufgerufen werden kann. Der initiale Start ist für uns entscheidend, danach hängt es ohnehin von anderen zusätzlichen Faktoren ab.

Die Voraussetzungen habe ich heute erstellt. Es gibt einen versteckten API-Endpunkt, der nicht über die bekannte REST-Engine zugänglich ist – und von dort aus, mit einem geheimen Token, kann man dann Caches invalidieren. Sixbot kann dann beim provisionieren kurz noch eine Zusatzaufgabe erleidigen. Thats IT!

Ziel ist es, die App bis Ende 2024 endlich fertigzustellen. Öhm, ein Jahr verspätet, aber trotzdem gut im Kurs. :rofl:

Erleichterung kommt auf, merkt ihr das? Yes, baby! Das nächste Projekt steht bald auch an - aber 6love hat mich schon geprägt :smiley:

Aktuell:

Profile - Edit → Cache Invalidierung wurde erfolgreich implementiert. Immer wenn du dein Profile updatest wird ein Signal ausgelöst, und das triggert dann Translations und neu auch Cache invalidierung.

Ads → reCreate & Edit Cache Invalidierung wurde implementiert.

Sofern es sich um Gold Inserate handelt wird die 1. Seite /home refresht.