Applications à usage intensif dans Mendix; 100 XNUMX utilisateurs simultanés

Le défi est lancé !

Ici à Mendix, nous aimons repousser les limites de notre plateforme. Nous aimons continuer à faire des choses plus grandes, meilleures et plus audacieuses jusqu'à ce qu'elles finissent par casser. Casser est, après tout, la meilleure façon de tester. Dans la poursuite de ce passe-temps séculaire, nous nous sommes demandé : « Combien d'utilisateurs simultanés pouvons-nous prendre en charge ? Mille ? Dix mille ? Et cent mille ? » Ce à quoi nous avons répondu : « Découvrons-le ! »

Que savons-nous?

Nous avons des clients dans le monde entier qui exécutent leurs applications sur Mendix Certaines sont de petites applications fonctionnant pour une poignée d'utilisateurs tandis que d'autres sont de véritables applications de niveau entreprise fonctionnant pour un grand nombre d'utilisateurs.

Par exemple, PostNL traite plus d'un million de commandes par jour avec son système de gestion des commandes, et la municipalité de Dubaï reçoit plus d'un million et demi de pages vues chaque mois. Nous savons donc que Mendix Les applications peuvent gérer de lourdes charges de travail. La question reste de savoir jusqu'à quel point nous pouvons les rendre lourdes.

À quoi ressemble notre test ?

Dans ce cas, un seul test consiste à voir un utilisateur effectuer plusieurs transactions. Notre objectif est d'obtenir que cent mille utilisateurs effectuent des transactions en même temps.

Commençons par définir une transaction. Qu'est-ce qu'une transaction terminée ? Nous recherchons une action de validation de base de données terminée, c'est-à-dire quelque chose qui ajoute de nouvelles données à la base de données. Il peut s'agir d'un enregistrement entièrement nouveau ou d'une modification d'un enregistrement existant. L'essentiel est que les données de la base de données soient modifiées de manière permanente par l'action.

Mendix est une plateforme gigantesque qui offre de nombreuses possibilités lors de la création d'applications. Cela nous a donné une multitude d'options pour choisir la manière de relever ce défi. Pour rester en phase avec une situation commerciale réelle, nous avons choisi une tâche relativement simple : une demande de remboursement de frais.

Le principe de base est qu'un utilisateur se connecte au système et envoie une série de demandes de remboursement simples. Nous avons choisi de laisser de côté les téléchargements de fichiers à ce stade afin que la quantité de données ne soit pas un facteur limitant. Nous voulions simplement évaluer à l'aide de transactions d'insertion et de mise à jour de base.

Comment nous avons mis en place notre Mendix test des limites de performance

Mise en œuvre de l'application

Pour notre application de test, nous avons commencé avec un modèle de base et avons ajouté quelques formulaires et fonctions très simples pour créer une application de dépenses. Le frontend a été réduit au minimum et aucun effort n'a été fait pour optimiser les images, le CSS ou les scripts. Notre attention s'est principalement portée sur la création de la logique en coulisses pour permettre nos tests.

Outil d'essai

Pour réaliser ces tests, nous avons utilisé un outil que nous utilisions déjà ailleurs dans l’entreprise : Gatling. Cet outil est conçu pour charger des plateformes de test à l’aide de scripts. Étant donné que nous avions déjà créé des scripts et l’expérience nécessaire pour les modifier, cela nous a semblé une option judicieuse. Cela nous a permis de créer un script de test qui exécuterait les tâches décrites ci-dessus à l’échelle dont nous avions besoin pour atteindre l’objectif que nous visions.

Point de départ des infrastructures

On va voir les choses en grand ou on rentre chez soi, n'est-ce pas ? La première chose que nous avons envisagée était de demander le plus grand nœud personnalisé que notre équipe de support pouvait provisionner. Cependant, nous ne serions pas en mesure d'implémenter le niveau de journalisation et d'avoir le niveau de contrôle dont nous aurions besoin pour faire fonctionner ce test. Mendix Cloud est conçu pour gérer la journalisation et les mesures en votre nom et est facile à gérer et à déployer. Il n'est pas conçu pour vous permettre d'ajouter un suivi personnalisé et de modifier la configuration. Nous avions donc besoin d'un environnement avec plus de contrôle manuel afin de repousser les limites et de faire des progrès !

Nous avons donc configuré notre première instance privée sur AWS EC2 et ajouté des analyses et des mesures personnalisées à l'aide de Grafana et d'InfluxDB pour suivre les performances des systèmes. Nous avons également installé un profileur asynchrone et YourKit pour observer directement l'exécution plus en détail. Pour simplifier les choses et nous permettre de les modifier facilement, nous avons utilisé un seul nœud pour héberger à la fois l'application et la base de données.

Exécution de notre test de limites de performances

Résultats de la première manche

Lorsque nous avons exécuté notre premier test sur cette configuration de serveur, nous avons réussi à atteindre un nombre respectable de 5000 XNUMX utilisateurs simultanés. C'était un bon début, mais ce n'était pas là où nous voulions être. Nous avons alors commencé à itérer sur notre configuration de serveur pour essayer d'obtenir autant de performances que possible.

Itérations et améliorations

Le premier changement a consisté à augmenter la taille de notre instance AWS EC 2, où nous avons doublé la taille, et à apporter quelques modifications aux paramètres Java et aux pools de bases de données. Cela nous a permis d'atteindre 7000 180 utilisateurs simultanés et XNUMX dépenses par seconde.

Nous avons ensuite séparé la base de données de l'instance principale et l'avons placée sur un nœud entièrement distinct. Nous avons également travaillé avec notre équipe d'opérations spéciales interne pour augmenter la taille de notre configuration. Cela nous a permis d'augmenter à nouveau notre nombre de transactions. Nous atteignions désormais 15,000 373 utilisateurs simultanés avec un débit de XNUMX dépenses par seconde.

Au cours de ces tests, nous avons également constaté des divergences dans notre script de test dans Gatling. Pour cette raison, nous avons apporté des modifications à la charge utile pour qu'elle ressemble davantage aux informations soumises par MxClient et avons modifié les valeurs soumises pour qu'elles correspondent mieux aux valeurs attendues.

Le grand pas suivant que nous avons réalisé a consisté à faire évoluer notre instance. Nous sommes passés à un paysage évolutif horizontal utilisant trois serveurs d'applications devant un serveur de base de données. Cette configuration nous a permis d'atteindre 30,000 700 utilisateurs simultanés avec un peu plus de XNUMX transactions par seconde, mais nous avons également remarqué un goulot d'étranglement réseau courant empêchant Gatling d'augmenter la charge.

Afin de contourner le goulot d'étranglement du réseau et de permettre à Gatling de fournir plus de charge, nous avons opté pour l'utilisation d'un plus grand nombre d'instances Gatling plus petites. Nous avons commencé par réutiliser l'un de nos nœuds d'application et avons créé la configuration ci-dessous.

Ces changements nous ont permis d'atteindre un niveau où nous avons pu gérer avec succès et de manière stable 25,000 XNUMX utilisateurs simultanés ! Le nombre total avait légèrement diminué, comme on pouvait s'y attendre, avec trois serveurs d'applications, mais c'était une configuration que nous pouvions adapter pour atteindre notre objectif.

Pour la dernière étape, c'est exactement ce que nous avons fait. Nous avons dimensionné la configuration pour supporter confortablement une augmentation d'un facteur quatre de la puissance de traitement, ce qui nous a permis d'obtenir un cluster avec quatre grands nœuds d'application et un serveur de base de données deux fois plus grand. Cela semble beaucoup, mais une entreprise qui s'attend à gérer le nombre d'utilisateurs simultanés que nous cherchons à atteindre devrait s'attendre à une infrastructure de cette envergure.

Une fois que nous avons eu les quatre serveurs d'applications, nous avons réussi à atteindre le chiffre magique de 100 XNUMX clients !

Les plats à emporter

Ce que nous avons prouvé, c'est que Mendix plate-forme et runtime, et donc un Mendix application, est tout à fait capable de gérer ce volume d'utilisateurs simultanés. Les informations que nous avons tirées de cet exercice concernant la configuration et le déploiement des serveurs ont été partagées avec notre équipe cloud et nous chercherons à améliorer notre infrastructure cloud à l'avenir. Nous espérons pouvoir contribuer à améliorer le niveau de performance de base déjà bon d'une norme Mendix Le nœud est capable de.

La prochaine fois, nous vous présenterons un guide plus détaillé des configurations que nous avons créées et des modifications que nous avons apportées pour obtenir ce résultat phénoménal.