Sådan forbedres MySQL AWS-ydeevne 2X over Amazon RDS til samme pris

AWS er ​​den #1 cloud-udbyder til open source-databasehosting og go-to-skyen til MySQL-implementeringer. Efterhånden som organisationer fortsætter med at migrere til skyen, er det vigtigt at komme foran præstationsproblemer, såsom høj latenstid, lav gennemstrømning og replikeringsforsinkelse med større afstande mellem dine brugere og cloud-infrastruktur. Mens mange AWS-brugere som standard bruger deres administrerede databaseløsning, Amazon RDS, er der alternativer tilgængelige, som kan forbedre din MySQL-ydeevne på AWS gennem avancerede tilpasningsmuligheder og ubegrænset EC2-instanstypeunderstøttelse. ScaleGrid tilbyder et overbevisende alternativ til hosting af MySQL på AWS, der tilbyder bedre ydeevne, mere kontrol og ingen cloud-leverandør lock-in og samme pris som Amazon RDS. I dette indlæg sammenligner vi ydeevnen af ​​MySQL Amazon RDS vs. MySQL Hosting hos ScaleGrid på AWS High Performance-instanser.

TLDR

ScaleGrid's MySQL på AWS High Performance-implementering kan give 2x-3x gennemløbet ved halvdelen af ​​forsinkelsen af ​​Amazon RDS til MySQL med deres ekstra fordel ved at have 2 læsereplikaer sammenlignet med 1 i RDS.

MySQL på AWS Performance Test

Som du kan se fra ovenstående tabel, er MySQL RDS-priser inden for $10 af ScaleGrids fuldt administrerede og altomfattende MySQL-hostingløsning.

Hvad er ScaleGrids højtydende replikasæt?

ScaleGrid MySQL på AWS High Performance replikasæt bruger en hybrid af lokal SSD og EBS disk for at opnå både høj ydeevne og høj pålidelighed. En typisk konfiguration implementeres ved hjælp af et 3-node replikasæt:

• Master og Slave-1 bruger lokale SSD-diske.
• Slave-2 bruger en EBS-disk (kan være generel eller en klargjort IOPS-disk).

Hvad betyder det? Da Master og Slave-1 kører på lokal SSD, får du den bedst mulige diskydeevne fra dine AWS-maskiner. Ikke mere netværksbaseret EBS, bare lynhurtig lokal SSD. Læser og skriver til din Primary, og endda læser fra Slave-1 vil fungere ved SSD-hastighed. Slave-2 bruger en EBS-datadisk, og du kan konfigurere den nødvendige mængde IOPS til din klynge. Denne konfiguration giver fuld sikkerhed for dine data, selv i tilfælde af at du mister de lokale SSD-diske.

ScaleGrids MySQL AWS High Performance XLarge replikasæt bruger i3.xlarge (30,5 GB RAM) instanser med lokal SSD til Master og Slave-1 og en i3.2xlarge (61 GB) RAM) forekomst for Slave-2.

MySQL-konfiguration

En lignende MySQL-konfiguration bruges på både ScaleGrid- og RDS-implementeringer:

MySQL Performance Benchmark-konfiguration

MySQL Performance Test Scenarier og resultater

For at sikre, at vi leverer informative resultater for alle MySQL AWS-arbejdsbelastningstyper, har vi opdelt vores tests i disse tre scenarier, så du kan evaluere baseret på din læse-/skrivebelastningsintensitet:

1. Læse-intensiv arbejdsbyrde: 80 % læser og 20 % skriver
2. Balanceret arbejdsbyrde: 50 % læser og 50 % skriver
3. Skriveintensiv arbejdsbyrde: 20 % læser og 80 % skriver

Hvert scenarie køres med varierende antal sysbench-klienttråde, der spænder fra 50 til 400, og hver test køres i en varighed på 10 minutter. Vi måler gennemløb i form af Queries Per Second (QPS) og 95. Percentile latency og sikrer, at den maksimale replikationsforsinkelse på slaverne ikke krydser 30'erne. For nogle af testene på ScaleGrid-implementeringen er MySQL-konfigurationen binlog_group_commit_sync_delay indstillet, så slavereplikeringsforsinkelsen ikke går ud over 30s. Denne teknik omtales som 'at bremse mesteren for at sætte fart på slaverne' og er forklaret i J-F Gagnes blog.

Scenario 1:Læseintensiv arbejdsbyrde med 80 % læsning og 20 % skrivning

Som vi kan se fra de læseintensive arbejdsbelastningstests, er ScaleGrid højtydende MySQL-instanser på AWS i stand til konsekvent at håndtere omkring 27.800 QPS overalt fra 50 op til 400 tråde. Dette er næsten en stigning på 200 % i forhold til MySQL RDS-ydeevne, som i gennemsnit kun er 9.411 QPS på tværs af det samme udvalg af tråde.

ScaleGrid opretholder også 53 % lavere latenstid i gennemsnit gennem hele MySQL AWS-ydelsestesten. Både Amazon RDS- og ScaleGrid-latenstiden stiger støt, efterhånden som antallet af tråde vokser, hvor ScaleGrid maksimalt er på 383 ms for 400 tråde, mens Amazon RDS er på 831 ms på samme niveau.

Scenario 2:Balanceret arbejdsbyrde med 50 % læsning og 50 % skrivning

I vores balancerede arbejdsbelastnings-ydeevnetest udkonkurrerer ScaleGrids MySQL High Performance-implementering på AWS igen med et gennemsnit på 20.605 QPS på tråde fra 50 til 400. Amazon RDS kun i gennemsnit 8.296 for det samme trådantal, hvilket resulterede i en forbedring på 148 % med ScaleGrid.

Både ScaleGrid- og Amazon RDS-forsinkelse faldt signifikant i de balancerede arbejdsbelastningstests sammenlignet med de læseintensive test, der er dækket ovenfor. Amazon RDS havde i gennemsnit 258 ms latency i de balancerede arbejdsbelastningstests, hvor ScaleGrid kun havde et gennemsnit på 125 ms og opnåede over en 52 % reduktion i latens i forhold til MySQL på Amazon RDS.

Scenario 3:Skriveintensiv arbejdsbyrde med 20 % læsning og 80 % skrivning

I vores sidste skriveintensive MySQL AWS-arbejdsbelastningsscenarie opnåede ScaleGrid en markant højere gennemløbsydelse med et gennemsnit på 17.007 QPS over intervallet 50 til 400 tråde. Dette er en forbedring på 123 % i forhold til Amazon RDS, der kun opnåede 7.638 QPS over det samme antal tråde.

95. percentil-latenstestene producerede også signifikant lavere latenstid for ScaleGrid med et gennemsnit på 114ms over 50 til 400 tråde. Amazon RDS opnåede et gennemsnit på 247 ms i deres latenstest, hvilket resulterede i en gennemsnitlig reduktion på 54 % i latens ved implementering af ScaleGrids High Performance MySQL på AWS-tjenester over Amazon RDS.

Analyse

Som vi observerede fra testresultaterne, resulterede læseintensive arbejdsbelastninger i både højere gennemløb og latens over afbalancerede arbejdsbelastninger og skriveintensive arbejdsbelastninger, uanset hvordan MySQL blev implementeret på AWS:

Forklaring af resultater

• Vi ser, at ScaleGrid MySQL på AWS-implementeringen gav tæt på 3x bedre gennemløb for den læseintensive arbejdsbyrde sammenlignet med RDS-implementeringen.
• Efterhånden som skrivebelastningen steg, selvom den absolutte gennemstrømning faldt, leverede ScaleGrid stadig tæt på 2,5 gange bedre gennemstrømningsydelse.
• For skrivetunge arbejdsbelastninger fandt vi ud af, at replikeringsforsinkelsen begyndte at træde ind for EBS-slaven på ScaleGrid-implementeringen. Da vores mål var at holde slavereplikeringsforsinkelsen inden for 30s for vores kørsler, introducerede vi binlog_group_commit_sync_delay for at sikre, at slaven kunne opnå bedre parallel eksekvering. Dette kontrollerede forsinkelsen og resulterede i mindre absolut gennemløb på ScaleGrid-implementeringen, men vi kunne stadig se en 2,2x bedre kapacitet sammenlignet med RDS-implementering.
• For alle de læseintensive, skriveintensive og balancerede arbejdsbelastningsscenarier tilbød ScaleGrid 0,5 gange lavere latensegenskaber sammenlignet med RDS.

ScaleGrid 'High Performance'-implementering kan give 2x-3x gennemløbet ved halvdelen af ​​RDS-forsinkelsen med en ekstra fordel ved at have 2 læsereplikaer sammenlignet med 1 i RDS. For at lære mere om ScaleGrids MySQL-hostingfordele i forhold til Amazon RDS til MySQL, tjek vores Sammenlign MySQL-udbydere side eller start en gratis 30-dages prøveperiode for at udforske den fuldt administrerede DBaaS-platform.