Das Erstellen von Anwendungen ist schwierig. Das Erstellen schneller Anwendungen ist noch schwieriger.
Warum geht es uns überhaupt um Geschwindigkeit?
Der Grund könnte nicht einfacher sein: Schnellere Anwendungen haben höhere Chancen, Nutzer zu gewinnen und zu binden¹. Unten findest du ein schönes Diagramm, das zeigt, wie die Konversionen der Nutzer sinken, wenn die Antwortzeiten steigen.

Die Konversationsraten der Benutzer sinken stark, wenn die Ladezeit der Seite zunimmt. Basierend auf echten Daten von Walmart. Die tatsächlichen Umrechnungsraten sind unbekannt, daher die fehlende Achse, aber die relativen Proportionen sind exakt. Credits an https://www.webloungedesign.com/development/how-and-why-to-optimize-the-image-on-the-site/
Einige von Ihnen mögen argumentieren: Ich muss mir keine Gedanken über Konversionsraten machen, meine ist eine Geschäftsprozessanwendung, meine Benutzer haben keine Wahl, sie müssen sie verwenden. Abgesehen davon, dass die Benutzer eine schreckliche Erfahrung gemacht haben (was Grund genug für IOP ist), muss man auch den Zeit- und Kostenaufwand des Benutzers, oder in diesem Fall der Mitarbeiter, berücksichtigen. Wenn zum Beispiel das Klicken auf eine Schaltfläche oder das Öffnen einer Seite 10 Sekunden dauert und ein Benutzer dies 100 Mal am Tag tut, dann werden 15 Minuten des Tages mit Warten verschwendet.
Aber das ist noch nicht das Ende. Es gab viele Studien was zeigt, dass Benutzer, die häufig länger warten (in der Regel über 5 Sekunden), wahrscheinlich dazu übergehen, während des Wartens etwas anderes zu tun (z. B. das Telefon überprüfen). Die Wahrscheinlichkeit steigt, je länger die Benutzer warten müssen. Bis die Benutzer wieder da sind, um den Fortschritt zu überprüfen, sind möglicherweise ein oder zwei Minuten vergangen. Dadurch können aus 10 Sekunden leicht eine Minute und aus 15 Minuten 90 Minuten am Tag verschwendet weil die Anwendung langsam reagiert.
Wie erstelle ich eine schnelle Mendix-Anwendung?
Die einfache Antwort lautet: Das tust du nicht. Das mag widersprüchlich erscheinen, wenn man bedenkt, wie ich gerade erklärt habe, dass Geschwindigkeit sehr wichtig ist, aber hör mir zu. Geschwindigkeit ist wichtig, aber das bedeutet nicht, dass sie Teil jeder User Story sein muss. Der einfache Grund dafür ist, dass es während der Entwicklung schwierig ist, vorherzusagen, welche Teile der Anwendung langsam sein werden. Es hat sich immer wieder gezeigt, dass Programmierer schlecht darin sind, Leistungsengpässe vorherzusagen.
Das ist völlig verständlich, wenn man bedenkt, dass die meisten Anwendungen heute auf einem komplexen Ökosystem mit mehreren „Blackbox-ähnlichen“ Abstraktions- und Erweiterungsebenen basieren. Darüber hinaus ist es praktisch unmöglich, anhand realer Daten vorherzusagen, wie leistungsfähig ein bestimmtes Design in der realen Welt sein wird. Die einzige Möglichkeit, mit Sicherheit etwas über die Leistung zu sagen, besteht darin, die Lösung bereitzustellen und die Leistung in der realen Welt zu messen.

Kredite an https://xkcd.com/1691/
Selbst wenn Programmierer Leistungsprobleme irgendwie vorhersagen könnten, könnte es dennoch eine schlechte Idee sein, während der regulären Entwicklung Zeit mit der Optimierung zu verbringen. Um ein Zitat zu wiederholen, das wahrscheinlich alle Programmierer bereits kennen: Vorzeitige Optimierung ist die Wurzel allen Übels. Einer der Hauptgründe dafür ist, dass Leistungsoptimierungen die Anwendung komplexer machen.
Im Laufe der Zeit, wenn die Anwendung wächst, werden immer mehr vorzeitige Optimierungen implementiert. Dies macht es zunehmend schwieriger, den vorhandenen Code zu pflegen und der App neue Funktionen hinzuzufügen. Mit anderen Worten, die Komplexität, die aufgrund von Leistungsoptimierungen entsteht, gerät in Konflikt mit anderen Softwarequalitätskennzahlen wie Wartbarkeit, Testbarkeit, Benutzerfreundlichkeit und anderen Fähigkeiten. Jetzt haben wir also ein klassisches Dilemma: Die Anwendung muss schnell sein und muss daher über Leistungsoptimierungen verfügen, aber gleichzeitig beeinträchtigen Optimierungen unsere Fähigkeit, die Anwendung zu warten und neue Funktionen hinzuzufügen.
Die Lösung...
besteht darin, eine vorzeitige Optimierung allein aufgrund des Bauchgefühls zu vermeiden. Stellen Sie stattdessen die Anwendung bereit und messen Sie die Leistung mit echten Daten und echten Benutzern. Wählen Sie auf der Grundlage der Messungen die am häufigsten verwendeten und langsamsten Teile der Anwendung aus und optimieren Sie diese. Wie bei vielen Aktivitäten üblich, ist der 80/20-Regel gilt auch hier, d. h. es ist wahrscheinlich möglich, die meisten (80%) der Leistungsprobleme mit nur geringem Aufwand (20%) zu beheben.
Da die Leistungsoptimierungen auf realen Daten basieren und nur dort implementiert werden, wo es wirklich notwendig ist, wird die Komplexität der Anwendung auf ein Minimum reduziert.
Wie misst man die Leistung einer Mendix-Anwendung?
Wie bereits erwähnt, müssen die Leistungsmessungen unter realen Bedingungen mit einer Kontrollgruppe von Benutzern oder mit allen Benutzern durchgeführt werden. Sie müssen überwachen, was die Benutzer tun und wie lange es dauert, Seiten zu laden und Klicks zu verarbeiten. Auf der Grundlage dieser Daten können Sie priorisieren, welche Seiten und Mikroflows zuerst optimiert werden sollen. Denken Sie daran, dass wir nach Aktivitäten suchen, deren Abschluss viel Zeit in Anspruch nimmt, aber auch nach Aktivitäten, die häufig vorkommen.
Zum Beispiel klingt ein Excel-Upload, der 30 Sekunden dauert, schrecklich. Aber wenn es nur einmal am Tag passiert, können Sie durch die Optimierung höchstens 30 Sekunden sparen. In den meisten Fällen ist dies den Entwicklungsaufwand nicht wert. Wenn andererseits das Öffnen einer bestimmten Seite 3 Sekunden dauert, es aber 1000 Mal pro Tag passiert, lohnt es sich wahrscheinlich, etwas Mühe zu investieren und die Ladezeit zu verkürzen. Wenn es den Entwicklern gelingt, die Ladezeit auf 1 Sekunde zu reduzieren, beträgt die Gesamtersparnis mehr als 30 Minuten pro Tag!
Was Sie also messen möchten, ist: Dauer von Microflows und Seitenladevorgängen sowie die Häufigkeit, mit der der Microflow aufgerufen oder die Seite geladen wird. Noch besser wäre es, wenn man direkt sehen könnte, wie viel jede Aktion in einem Microflow und jedes Widget auf einer Seite zur Antwortzeit beiträgt.
Werkzeuge
Es gibt viele Möglichkeiten, die Leistung einer Webanwendung zu überwachen. Die einfachste Methode besteht darin, Protokollanweisungen manuell hinzuzufügen. Das lässt sich natürlich nicht gut skalieren und verunreinigt den Code mit ablenkenden Protokollanweisungen. Ein besserer Weg ist die Verwendung eines Tools zur Überwachung. Mendix basiert auf Java, sodass Tools zur Überwachung von Java auch für Mendix-Anwendungen funktionieren. Zu diesen Tools gehören JMX, AppDynamics und NewRelic. Diese Tools funktionieren jedoch auf der niedrigen Java-Ebene von Funktionen und Klassen, und es erfordert zusätzlichen Aufwand, die Metriken mit der Mendix-Ebene von Microflows und Seiten in Beziehung zu setzen.

Eine weitere Option ist die Verwendung von APM, einem Tool zur Leistungsüberwachung, das speziell für die Mendix-Plattform entwickelt wurde. APM erfasst und meldet sofort Kennzahlen zu den Ladezeiten von Seiten und Mikroflows (Durchschnitt, Gesamtwert und 90 Perzentil²) sowie zur Anzahl der Ausführungen. Darüber hinaus wird die Dauer jeder Aktion in einem Microflow und jedes HTTP-Aufrufs beim Öffnen einer Seite angezeigt. All diese Informationen sind auf der Mendix-Ebene von Seiten, Widgets, Microflows und Aktionen logisch organisiert und dargestellt. Auf diese Weise können Sie ganz einfach feststellen, in welchen Teilen Ihrer Anwendung Leistungsprobleme auftreten.
Zusammenfassung
Dieser Blogbeitrag ist Teil einer Reihe, die sich auf Leistung konzentriert. Es wird ein übergeordnetes Verfahren zur Behandlung von Leistungsproblemen in einer Mendix-Anwendung vorgestellt. Außerdem wird beschrieben, wie und welche Metriken erfasst werden müssen, um Leistungsprobleme am besten zu diagnostizieren.
In den nächsten beiden Beiträgen werden wir uns mit konkreten Leistungsproblemen in einer Mendix-Anwendung befassen. Ich zeige Ihnen, wie Sie Leistungsengpässe erkennen und beheben können.
Fortsetzung folgt...
Finden Sie heraus, wie CLEVR die Wirkung Ihres Unternehmens steigern kann
FAQ
Can't find the answer to your question? Just get in touch