Firebird Performance Nieuwsbrief: Editie 1

We hebben besloten om een min of meer regelmatige “Firebird performance nieuwsbrief” te lanceren, gewijd aan prestatietests, tips, trucs, configuratieverbeteringen, enz.

In het eerste nummer hebben we het volgende:

• Firebird 4 vs Firebird 3 schrijfprestaties vergelijken,
• De beste AWS EC2-instantie kiezen voor maximale Firebird schrijfprestaties,
• Recente resultaten van de INSERT/UPDATE/DELETE-test

Firebird 4 vs Firebird 3: Goed Nieuws, Iedereen!

Sinds 2019, toen we de eerste verzameling resultaten van de eenvoudige INSERT/UPDATE/DELETE-test publiceerden, hebben veel mensen ons resultaten van hun Firebird-servers gestuurd, en we hebben ze toegevoegd aan het spreadsheet en de bijbehorende grafiek.

De test is een eenvoudig maar krachtig hulpmiddel om de prestaties van verschillende hardware+Firebird-configuraties te meten en te vergelijken, om snel hardware- of configuratieproblemen te bevestigen of te weerleggen.

Onlangs hebben we deze test gebruikt om de INSERT/UPDATE/DELETE-prestaties van Firebird 4.0 (versie 4.0.0.2394, een paar builds van de release) en 3.0 (versie 3.0.8.33426, snapshot, pre-release van de aankomende 3.0.8, het is stabiel als een minor release, volgens de Firebird auto-tests) te vergelijken.

De testomgeving was Intel i3-10100F 3.60GHz met SSD Samsung SSD 870QVO en RAM-schijf (qSoft), met verschillende hoeveelheden RAM (16,32,64) en Page Buffers.

Hieronder staat de grafiek, en hier is het XLS-spreadsheet met de resultaten.

Zoals je kunt zien, is Firebird 4 onder dezelfde omstandigheden en met dezelfde configuratie ongeveer 10% sneller dan 3.0.8 bij schrijfbewerkingen. Dit is zeker goed nieuws en nog een teken dat het tijd is om de aankomende release nader te bekijken en voorbereidingen te treffen voor de migratie.

Natuurlijk is de beste aanpak om dezelfde test op je eigen server uit te voeren en de daadwerkelijke verbetering zelf te zien.

Zie hoe je het doet »

De beste AWS EC2-instantie kiezen voor maximale Firebird schrijfprestaties

Steeds meer bedrijven denken aan “verhuizen naar de cloud”, en Amazon Web Service Elastic Cloud is een van de favoriete “cloudbestemmingen”.

AWS biedt echter veel verschillende instantie-types, hoe kies je de beste? Natuurlijk, doe de tests!

We hebben de eenvoudige INSERT/UPDATE/DELETE-tests uitgevoerd voor de 20 instantie-types en verschillende echt goede opties voor Firebird gevonden.

Houd er rekening mee - alle prijzen in de berekeningen en grafieken hieronder zijn voor de Frankfurt-regio van AWS EC2, ze zijn overgenomen van aws.amazon.com, zonder kortingen, ze kunnen onderworpen zijn aan extra belastingen, en ze kunnen in de loop van de tijd veranderen - dus beschouw de prijzen hieronder niet als definitief of als een exacte aankoopgids.

Hier is de algemene grafiek en XLS-spreadsheet met resultaten:

Voor de eenvoud hebben we de kolom Operations gemaakt, die in wezen een som is van Inserts+Updates+Deletes, en deze gebruikt als de verenigde schrijfprestatiemetriek:

Zoals je kunt zien, zijn de volgende 3 instantie-types leiders in prestaties (vanuit het oogpunt van Firebird schrijfbewerkingen):

Instantie	Uurprijs voor Linux	Operations/per seconde

| z1d.xlarge | USD$0.45 | 45834 | | m5dn.2xlarge | USD$0.648 | 45198 | | m5d.2xlarge | USD$0.544 | 44150 |

Interessant is dat de leiders niet de duurste instantie-types zijn! Natuurlijk moeten we in gedachten houden dat de test single-threaded is (en geen voordeel haalt uit het aantal kernen), en geen grote hoeveelheid RAM vereist (omdat de database slechts 3,6 GB is), maar voor applicaties die snel piekbelastingen van schrijfbewerkingen moeten verwerken, zien deze instanties er echt optimaal uit.

Ondanks het feit dat deze instantie-types niet de duurste zijn (van de geteste), zijn ze nog steeds duur genoeg om twee keer na te denken over het budget, en aangezien een van de geadverteerde voordelen van de cloud flexibiliteit is, is het logisch om te beginnen met goedkopere VM-instantie-types, die goed genoeg zouden kunnen zijn om onze Firebird-database te bedienen, toch?

Om de optimale kosten/prestaties instantie-types te vinden, hebben we een andere kolom in ons spreadsheet gemaakt: “Operations per 1 USD”.

Het betekent precies wat het betekent - hoeveel schrijfbewerkingen je kunt kopen voor 1 USD.

De formule is als volgt:

Operations_Per_Second * 3600 seconden per uur / Prijs per uur

Zoals je kunt zien, zijn vanuit dit oogpunt de leiders anders:

Instantie	Linux uurprijs	Operations per 1 USD	Operations per seconde
c5d.xlarge	USD$0,222	579062087	35709
c5ad.xlarge	USD$0,2	565024995	31390
m5dn.xlarge	USD$0,324	446037216	40143

Zeer interessant is #3, m5dn.xlarge met piekprestaties ~40K/per seconde - het ligt vrij dicht bij de prestatieleider z1d.xlarge met 45834 operations/seconde, maar is aanzienlijk goedkoper.

Over het algemeen toont onze ervaring met AWS EC2 aan dat het een stabiele, volwassen omgeving is, met veel goede beveiligings-/back-up-/hoge beschikbaarheids-/etc. functies, maar zoals elk complex platform vereist het ervaring (of externe expertise) om de juiste keuze te maken en geen overweldigende rekeningen te betalen voor applicaties met een niet-fantastische belasting.

Recente resultaten van de INSERT/UPDATE/DELETE-test

Dus, zoals je kunt zien, kan de eenvoudige test niet alleen nuttig zijn als vergelijking tussen hardware en Firebirds, maar kan het je ook een paar dollar besparen.

We hebben een grafiek gepubliceerd met recent verzamelde resultaten en een XLS-spreadsheet om ermee te spelen, zodat je het zelf kunt bekijken hier.

Hieronder staan 3 duidelijke conclusies:

1. NVME-schijven zijn echt geweldig, dus als je een krachtige Firebird-server nodig hebt, koop dan NVME voor databases.
2. De hoge CPU-frequentie is erg belangrijk voor de hoge prestaties van Firebird-databases. Vaak duwen leveranciers je naar multi-coreprocessors met lagere frequentie (<3Ghz), maar dit is mogelijk niet de beste optie voor Firebird, en minder kernen met hogere frequentie kunnen een beter resultaat geven.
3. Als je databasebelastingprofiel sterk schrijfgericht is, probeer dan Page Buffers te verminderen: experimenteer met DefaultDbCachePages zoals 50K, 100K, 250K, enz. Het zou cool zijn als je de resultaten met ons deelt!

Voel je vrij om testresultaten te onderzoeken, en stel gerust vragen of stuur suggesties.

In de volgende nummers van “Firebird Performance Nieuwsbrief”

In het 2e nummer laten we zien hoe je meerdere SuperClassic-instanties configureert om één database te bedienen (onder andere kan dit nuttig zijn om de belasting over meerdere netwerkpoorten te verdelen). De plannen voor de volgende nummers zijn groot: configuratiefouten, tests van versleutelde databases, geavanceerde vergelijking van Firebird 4-prestaties met Firebird 3, optimalisatie van indices, enz.

Als je geïnteresseerd bent en meldingen over nieuwe nummers wilt ontvangen, sluit je dan aan bij ons op FirebirdSQL Telegram-kanaal.

Neem contact met ons op

Neem contact met ons op met vragen en suggesties: Alexey Kovyazin: [email protected].