Så før du investerer meget tid og energi i en bestemt sky, er det vigtigt at forstå de overordnede præstationskarakteristika for MongoDB på den sky. Vi ledte efter denne information og fandt den ikke – så vi besluttede at sammensætte den for dig som en del af vores præstationsserie.
The Benchmark Rig
Vi besluttede at sammenligne AWS, Azure og DigitalOcean til denne test. To forskellige sæt konfigurationer blev valgt. Tabellen nedenfor opsummerer maskinkonfigurationerne:
Udbyder | Region | ScaleGrid Medium* (Cores/RAM/Disk/Prov IOPS) | ScaleGrid Large* (Cores/RAM/Disk/Prov IOPS) |
AWS | US East | 1/3,75 GB/60 GB/300 | 2/7,5 GB/120 GB/500 |
Azure | Østlige USA | 2/3,5 GB/60 GB/op til 2000 | 4/7GB/120GB/op til 4000 |
DigitalOcean | New York 3 | 2/4GB/25GB/SSD** | 4/8GB/35GB/SSD** |
* Se her under "MongoDB Hosting" for at få oplysninger om maskinkonfigurationer.
** DigitalOcean har direkte tilsluttede SSD'er.
Benchmark-ydeevnetestene blev kørt ved hjælp af YCSB Workload A (update heavy workload). Vi talte om YCSB, opsætningen af det og dets arbejdsbelastninger i et meget detaljeret indlæg i sidste måned.
- Alle benchmarktests blev udført i en selvstændig konfiguration
- For begge konfigurationer, 5 millioner poster blev indsat med forskellige niveauer af serverbelastning (baseret på antallet af klienttråde).
- For Medium-konfigurationen blev Workload A udført med standardværdier (50 % opdatering, 50 % læst) med operationsantal på 5 millioner på forskellige niveauer af serverbelastning.
- For den store konfiguration blev Workload A udført med standardværdier (50 % opdatering, 50 % læst) med operationsantal på 10 millioner på forskellige niveauer af serverbelastning.
Resultater
Vi vil diskutere resultater baseret på insert-ydeevne og gennemløbs-/latency-karakteristika under opdateringens tunge arbejdsbyrde.
Indsæt ydeevne
Mellem forekomster
Gennemløbs-/latensegenskaberne for indsættelse af 5M post på Medium-konfigurationen:
Store forekomster
Gennemløbs-/latensegenskaberne for indsættelse af 5M-poster på Large-konfigurationen:
Opdater ydeevne
Mellem forekomster
Gennemløbs-/latensegenskaberne for 5M skrive/opdateringsoperationer på mediekonfigurationen:
Testen blev kørt med 32 tråde kun for DigitalOcean. AWS og Azure var flade foringer med 16 gevind. DigitalOcean giver dog indtryk af at skalere lineært indtil 32 tråde.
Store forekomster
Gennemløbs-/latensegenskaberne for 10M skrive-/opdateringsoperationer på den store konfiguration:
Samlet analyse
- Som forventet har MongoDB på DigitalOcean konsekvent høj gennemløb/lav latency karakteristika hele vejen igennem og slår de andre hænder ned under indsættelsesfasen og trækker den maksimale juice ud af dets lokale SSD-drev. Interessant nok, selvom det går meget godt under læse/opdateringsfasen, giver andre udbydere det en del konkurrence, især når serverbelastningen stiger. Det er klart, at AWS/Azure bruger meget højere gennemløbsnetværkslagring.
- For at få bedre ydeevne fra AWS-disk kan brugeren bruge større diskstørrelser eller allokere mere klargjort IOPS.
- På mellemstore forekomster ser MongoDB på Azure ud til at klare sig meget bedre end AWS konsekvent, både under indsættelse og derefter opdatering/læsefase. Dette var overraskende. Hardwaren er ret jævnt afstemt. På store forekomster er AWS-ydeevne markant bedre end Azure.
- Både AWS og Azure forringes i latenser ret godt, efterhånden som belastningen øges. Azure ser ud til at have en ret god latensnedbrydningskurve.
- Et andet interessant aspekt af MongoDB på AWS ydeevne hele vejen igennem er, hvor "flad-linet" det er:Ser ud til at nedbrydes yndefuldt selv på en log-skala.
- Baseret på forsinkelsestal, ligner sweet spot, set fra et belastningssynspunkt, for mellemstore og store forekomster henholdsvis 8 og 16 tråde.