Ainsi, avant d'investir beaucoup de temps et d'énergie dans un cloud particulier, il est important de comprendre les caractéristiques de performance globales de MongoDB sur ce cloud. Nous avons recherché ces informations et ne les avons pas trouvées. Nous avons donc décidé de les rassembler pour vous dans le cadre de notre série de performances.
La plate-forme de référence
Nous avons décidé de comparer AWS, Azure et DigitalOcean pour ce test. Deux ensembles différents de configurations ont été choisis. Le tableau ci-dessous résume les configurations de la machine :
Fournisseur | Région | ScaleGrid Medium* (Cœurs/RAM/Disque/Prov IOPS) | ScaleGrid Large* (Cœurs/RAM/Disque/Prov IOPS) |
AWS | USA Est | 1/3,75 Go/60 Go/300 | 2/7,5 Go/120 Go/500 |
Azur | Est des États-Unis | 2/3,5 Go/60 Go/jusqu'à 2 000 | 4/7 Go/120 Go/jusqu'à 4 000 |
DigitalOcean | New York 3 | 2/4 Go/25 Go/SSD** | 4/8 Go/35 Go/SSD** |
* Reportez-vous ici sous "MongoDB Hosting" pour les détails des configurations de machine.
** DigitalOcean a des SSD directement connectés.
Les tests de performances de référence ont été exécutés à l'aide de la charge de travail A du YCSB (mise à jour de la charge de travail lourde). Nous avons parlé du YCSB, de sa configuration et de ses charges de travail dans un article très détaillé le mois dernier.
- Tous les tests de performances ont été effectués dans une configuration autonome
- Pour les deux configurations, 5 millions d'enregistrements ont été insérés avec différents niveaux de charge du serveur (basés sur le nombre de threads clients).
- Pour la configuration moyenne, la charge de travail A a été exécutée avec les valeurs par défaut (50 % de mise à jour, 50 % de lecture) avec un nombre d'opérations de 5 millions à différents niveaux de charge du serveur.
- Pour la grande configuration, la charge de travail A a été exécutée avec les valeurs par défaut (50 % de mise à jour, 50 % de lecture) avec un nombre d'opérations de 10 millions à différents niveaux de charge du serveur.
Résultats
Nous discuterons des résultats en fonction des performances d'insertion et des caractéristiques de débit/latence sous une charge de travail importante de mise à jour.
Insérer les performances
Instances moyennes
Les caractéristiques de débit/latence pour l'insertion d'enregistrements de 5 M sur la configuration moyenne :
Grandes instances
Les caractéristiques de débit/latence pour l'insertion d'enregistrements de 5 M sur la configuration Large :
Mettre à jour les performances
Instances moyennes
Les caractéristiques de débit/latence pour 5 M d'opérations d'écriture/mise à jour sur la configuration moyenne :
Le test a été exécuté avec 32 threads pour DigitalOcean uniquement. AWS et Azure étaient des doublures plates à 16 fils. Cependant, DigitalOcean donne l'impression d'évoluer linéairement jusqu'à 32 threads.
Grandes instances
Les caractéristiques de débit/latence pour 10 M d'opérations d'écriture/mise à jour sur la configuration Large :
Analyse globale
- Comme prévu, MongoDB sur DigitalOcean a constamment des caractéristiques de débit élevé/faible latence et bat haut la main les autres pendant la phase d'insertion, en extrayant le maximum de jus de ses disques SSD locaux. Fait intéressant, même s'il se passe très bien pendant la phase de lecture/mise à jour, d'autres fournisseurs lui font un peu concurrence, surtout lorsque la charge du serveur augmente. Il est clair qu'AWS/Azure utilisent un stockage en réseau à débit beaucoup plus élevé.
- Afin d'obtenir de meilleures performances du disque AWS, l'utilisateur peut utiliser des tailles de disque plus importantes ou allouer davantage d'IOPS provisionnés.
- Sur les instances moyennes, MongoDB sur Azure semble faire bien mieux qu'AWS de manière cohérente, à la fois pendant les phases d'insertion et de mise à jour/lecture. C'était surprenant. Le matériel est assez homogène. Sur les grandes instances, les performances d'AWS sont nettement meilleures qu'Azure.
- AWS et Azure dégradent assez bien les latences à mesure que la charge augmente. Azure semble avoir une assez bonne courbe de dégradation de la latence.
- Un autre aspect intéressant des performances de MongoDB sur AWS est à quel point il est "plat" :il semble se dégrader gracieusement même à l'échelle logarithmique.
- Sur la base des nombres de latences, il semble que le point idéal, du point de vue de la charge, pour les instances moyennes et grandes soit respectivement de 8 et 16 threads.