Schieben Mendix Leistungsgrenzen | Mendix

Direkt zum Inhalt

Schieben Mendix Leistungsgrenzen

Schieben Mendix Bild

Als Low-Code-Plattform Mendix ist für alle Arten von Unternehmen unterschiedlicher Größe ausgelegt. Dies ist einer der Gründe für unsere knotenbasierte Bereitstellung. Sie können damit die beste Verarbeitungsleistung für Ihre Anwendung auswählen – nicht zu viel, nicht zu wenig, sondern genau richtig.

Auf diese Weise können Sie Leistung und Kosten ins Gleichgewicht bringen. Außerdem können Sie klein anfangen und Ihre Anwendung dann skalieren, wenn Sie mehr Benutzer gewinnen.

Was passiert aber, wenn Ihre Anwendung richtig durchstartet? Wenn Ihre Benutzerbasis sprunghaft ansteigt und die Anzahl der Transaktionen, die Sie verarbeiten müssen, exponentiell zunimmt? Kann Mendix schaffen?

Anwendungen mit hoher Nutzung in Mendix; 100 gleichzeitige Benutzer

Die Herausforderung ist gestellt!

Hier, um Mendix, wir treiben unsere Plattform gerne an ihre Grenzen. Wir machen die Dinge immer größer, besser und mutiger, bis sie irgendwann kaputt gehen. Schließlich ist das Zerbrechen die beste Art zu testen. Bei diesem altbewährten Zeitvertreib haben wir uns gefragt: „Wie viele gleichzeitige Benutzer können wir unterstützen? Tausend? Zehntausend? Und wie wäre es mit hunderttausend?“ Darauf antworteten wir: „Lass es uns herausfinden!“

Was wissen wir?

Wir haben Kunden auf der ganzen Welt, die ihre Anwendungen auf dem Mendix Plattform. Manche davon sind kleine Apps, die für eine Handvoll Benutzer laufen, während andere echte Anwendungen auf Unternehmensebene sind, die für eine große Anzahl von Benutzern laufen.

So verarbeitet beispielsweise PostNL über eine Million Bestellungen pro Tag mit seinem Auftragsmanagementsystem, und die Stadtverwaltung von Dubai verzeichnet jeden Monat über eineinhalb Millionen Seitenaufrufe. Wir wissen also, dass Mendix Anwendungen können große Arbeitslasten bewältigen. Die Frage bleibt: Wie groß können wir sie machen?

Wie sieht unser Test aus?

Ein einzelner Test besteht in diesem Fall darin, dass ein Benutzer mehrere Transaktionen abschließt. Unser Ziel ist es, dass hunderttausend Benutzer gleichzeitig Transaktionen abschließen.

Definieren wir zunächst eine Transaktion. Was ist eine abgeschlossene Transaktion? Wir suchen nach einer abgeschlossenen Datenbank-Commit-Aktion – etwas, das der Datenbank neue Daten hinzufügt. Es könnte sich um einen völlig neuen Datensatz handeln oder um eine Änderung eines vorhandenen Datensatzes. Entscheidend ist, dass die Daten in der Datenbank durch die Aktion dauerhaft geändert werden.

Mendix ist eine riesige Plattform, die viele verschiedene Möglichkeiten beim Erstellen von Anwendungen bietet. Dies gab uns eine Unmenge an Optionen, als wir uns entschieden, wie wir diese Herausforderung angehen wollten. Um es einer tatsächlichen Geschäftssituation anzupassen, wählten wir eine relativ einfache Aufgabe: eine Spesenabrechnung.

Das Grundprinzip besteht darin, dass sich ein Benutzer beim System anmeldet und eine Reihe einfacher Spesenabrechnungen sendet. Wir haben uns entschieden, an dieser Stelle auf Datei-Uploads zu verzichten, damit die Datenmenge keinen einschränkenden Faktor darstellt. Wir wollten es nur anhand einfacher Einfüge- und Aktualisierungstransaktionen auswerten.

Wie wir unsere Mendix Leistungsgrenzentest

App-Implementierung

Für unsere Testanwendung haben wir mit einer einfachen Vorlage begonnen und einige sehr einfache Formulare und Funktionen hinzugefügt, um eine Spesenanwendung zu erstellen. Das Frontend wurde auf ein Minimum beschränkt und es wurde kein Versuch unternommen, Bilder, CSS oder Skripte zu optimieren. Unser Hauptaugenmerk lag auf der Erstellung der Logik hinter den Kulissen, um unsere Tests zu ermöglichen.

Schieben Mendix Leistungsgrenzen_Aufwendungen einreichen Microflow

Testwerkzeug

Zur Durchführung dieser Tests haben wir ein Tool verwendet, das wir bereits anderswo im Unternehmen verwendet haben: Gatling. Dieses Tool ist dafür konzipiert, Testplattformen mithilfe von Skripten zu laden. Da wir bereits einige Skripte erstellt hatten und über die nötige Erfahrung verfügten, um diese zu ändern, schien dies eine sinnvolle Option zu sein. So konnten wir ein Testskript erstellen, das die oben beschriebenen Aufgaben in dem Umfang ausführen würde, den wir brauchten, um das angestrebte Ziel zu erreichen.

Infrastrukturelle Ausgangslage

Ganz oder gar nicht, oder? Als Erstes haben wir überlegt, den größten benutzerdefinierten Knoten anzufordern, den unser Support-Team bereitstellen konnte. Allerdings wären wir nicht in der Lage gewesen, das Protokollierungsniveau zu implementieren und die Kontrolle zu haben, die wir brauchen würden, um diesen Test erfolgreich durchzuführen. Unsere Mendix Die Cloud ist darauf ausgelegt, Protokollierung und Metriken in Ihrem Namen zu handhaben und ist einfach zu verwalten und bereitzustellen. Sie ist nicht dafür gedacht, dass Sie maßgeschneiderte Nachverfolgung hinzufügen und an der Konfiguration herumfummeln können. Daher brauchten wir eine Umgebung mit mehr manueller Kontrolle, um die Grenzen zu erweitern und Dinge kaputt zu machen!

Also richteten wir unsere erste private Instanz auf AWS EC2 ein und fügten einige benutzerdefinierte Analysen und Metrikerfassungen mit Grafana und InfluxDB hinzu, um die Leistung der Systeme zu verfolgen. Wir installierten auch einen asynchronen Profiler und YourKit, um die Laufzeit direkt und detaillierter zu beobachten. Um die Dinge einfach zu halten und uns zu ermöglichen, Dinge einfach zu ändern, verwendeten wir einen einzigen Knoten, um sowohl die Anwendung als auch die Datenbank zu hosten.

Durchführung unseres Leistungsgrenztests

Ergebnisse des ersten Durchlaufs

Als wir unseren ersten Test auf diesem Server-Setup durchführten, erreichten wir beachtliche 5000 gleichzeitige Benutzer. Das war ein guter Anfang, aber noch nicht das, was wir erreichen wollten. Dann begannen wir, unser Server-Setup zu iterieren, um so viel Leistung wie möglich herauszuholen.

Schieben Mendix Leistungsgrenzen_Leistungsdiagramm

Iterationen und Verbesserungen

Die erste Änderung bestand darin, die Größe unserer AWS EC 2-Instanz zu erhöhen, indem wir die Größe verdoppelten und einige Änderungen an den Java-Einstellungen und Datenbankpools vornahmen. Dadurch erreichten wir 7000 gleichzeitige Benutzer und 180 Ausgaben pro Sekunde.

Als Nächstes haben wir die Datenbank von der Hauptinstanz getrennt und sie vollständig auf einem separaten Knoten abgelegt. Außerdem haben wir mit unserem internen Spezialteam daran gearbeitet, die Größe unseres Setups zu erhöhen. Dies führte dazu, dass wir unsere Transaktionsanzahl erneut erhöhen konnten. Jetzt erreichten wir 15,000 gleichzeitige Benutzer mit einem Durchsatz von 373 Ausgaben pro Sekunde.

Im Laufe dieser Tests stellten wir auch Unstimmigkeiten in unserem Testskript in Gatling fest. Aus diesem Grund nahmen wir Änderungen an der Nutzlast vor, damit sie den vom MxClient übermittelten Informationen ähnlicher ist, und nahmen Änderungen an den übermittelten Werten vor, damit sie besser zu den erwarteten Werten passen.

Der nächste große Sprung, den wir machten, war die Skalierung unserer Instanz. Wir wechselten zu einer horizontal skalierten Landschaft mit drei Anwendungsservern vor einem Datenbankserver. Mit diesem Setup konnten wir 30,000 gleichzeitige Benutzer mit etwas über 700 Transaktionen pro Sekunde erreichen, aber wir bemerkten auch einen häufigen Netzwerkengpass, der Gatling daran hinderte, die Last zu erhöhen.

Um den Netzwerkengpass zu umgehen und Gatling mehr Last zu ermöglichen, sind wir dazu übergegangen, eine größere Anzahl kleinerer Gatling-Instanzen zu verwenden. Wir haben zunächst einen unserer Anwendungsknoten umfunktioniert und das folgende Setup erstellt.

Schieben Mendix Leistungsgrenzen_Überarbeitetes Anwendungsknoten-Setup

Diese Änderungen haben uns an den Punkt gebracht, an dem wir erfolgreich und stabil 25,000 gleichzeitige Benutzer ermöglichen konnten! Die Gesamtzahl war, wie zu erwarten, leicht gesunken, da wir drei Anwendungsserver hatten, aber dies war ein Setup, das wir skalieren konnten, um unser Ziel zu erreichen.

Für den letzten Anstoß haben wir genau das getan. Wir haben das Setup so skaliert, dass es eine Steigerung der Verarbeitungsleistung um den Faktor vier problemlos unterstützt, und sind so zu einem Cluster mit vier großen App-Knoten und einem doppelt so großen DB-Server gekommen. Das scheint viel zu sein, aber ein Unternehmen, das die von uns angestrebte Anzahl gleichzeitiger Benutzer bewältigen will, muss mit einer Infrastruktur dieser Größenordnung rechnen.

Schieben Mendix Leistungsgrenzen_Skaliertes Anwendungsknoten-Setup

Nachdem wir die vier App-Server hatten, haben wir es geschafft, die magische Marke von 100 Kunden zu knacken!

Das Essen zum Mitnehmen

Was wir bewiesen haben, ist, dass die Mendix Plattform und Laufzeit und damit eine Mendix Anwendung, ist absolut in der Lage, dieses Volumen gleichzeitiger Benutzer zu bewältigen. Die Erkenntnisse, die wir aus dieser Übung hinsichtlich der Konfiguration und Bereitstellung von Servern gewonnen haben, wurden mit unserem Cloud-Team geteilt und wir werden in Zukunft versuchen, unsere Cloud-Infrastruktur zu verbessern. Hoffentlich können wir dazu beitragen, das bereits gute Grundniveau der Leistung eines Standards zu verbessern Mendix Knoten kann.

Schieben Mendix Leistungsgrenzen_Build- und Benutzerdiagramm

Nächstes Mal folgt eine ausführlichere Anleitung zu den Setups, die wir erstellt haben, und den Änderungen, die wir vorgenommen haben, um dieses phänomenale Ergebnis zu erzielen.

Schieben Mendix Leistungsgrenzen_Immer mit Kuchen feiern

Wählen Sie Ihre Sprache