Firebird Performance Newsletter: Wydanie 1
Postanowiliśmy uruchomić mniej lub bardziej regularny „biuletyn o wydajności Firebirda”, poświęcony testom wydajności, wskazówkom, trikom, ulepszeniom konfiguracji itp.
W pierwszym wydaniu mamy:
- Porównanie wydajności zapisu Firebird 4 vs Firebird 3,
- Wybór najlepszej instancji AWS EC2 dla maksymalnej wydajności zapisu Firebirda,
- Najnowsze wyniki testu INSERT/UPDATE/DELETE
Firebird 4 vs Firebird 3: Dobre wieści dla wszystkich!
Od 2019 roku, kiedy opublikowaliśmy pierwszą kolekcję wyników prostego testu INSERT/UPDATE/DELETE, wiele osób przesłało nam wyniki ze swoich serwerów Firebird, a my dodaliśmy je do arkusza kalkulacyjnego i odpowiedniego wykresu.
Test jest prostym, ale potężnym narzędziem do mierzenia i porównywania wydajności różnych konfiguracji sprzętu + Firebirda, pozwalającym szybko potwierdzić lub obalić problem ze sprzętem lub konfiguracją.
Ostatnio użyliśmy tego testu do porównania wydajności INSERT/UPDATE/DELETE Firebirda 4.0 (wersja 4.0.0.2394, kilka buildów przed wydaniem) i 3.0 (wersja 3.0.8.33426, snapshot, przedpremierowa wersja nadchodzącego 3.0.8, jest stabilna jak wydanie mniejsze, zgodnie z autotestami Firebirda).
Środowisko testowe to Intel i3-10100F 3.60GHz z dyskiem SSD Samsung SSD 870QVO i dyskiem RAM (qSoft), z różnymi rozmiarami RAM (16, 32, 64) i Page Buffers.
Poniżej znajduje się wykres, a tutaj jest arkusz XLS z wynikami.

Jak widać, w tych samych warunkach i przy tej samej konfiguracji Firebird 4 jest około 10% szybszy niż 3.0.8 w operacjach zapisu. To zdecydowanie dobra wiadomość i kolejny znak, że czas przyjrzeć się bliżej nadchodzącemu wydaniu i rozpocząć przygotowania do migracji.
Oczywiście najlepszym podejściem będzie uruchomienie tego samego testu na własnym serwerze i zobaczenie rzeczywistej poprawy na własne oczy.
Zobacz jak to zrobić »
Wybór najlepszej instancji AWS EC2 dla maksymalnej wydajności zapisu Firebirda
Coraz więcej firm myśli o „przejściu do chmury”, a Amazon Web Service Elastic Cloud jest jednym z ulubionych „celów chmurowych”.
Jednak AWS oferuje wiele różnych typów instancji - jak wybrać najlepszą? Oczywiście, przeprowadzić testy!
Wykonaliśmy proste testy INSERT/UPDATE/DELETE dla 20 typów instancji i znaleźliśmy kilka naprawdę dobrych opcji dla Firebirda.
Uwaga - wszystkie ceny w obliczeniach i wykresach poniżej dotyczą regionu Frankfurt AWS EC2, są pobrane bezpośrednio z aws.amazon.com, bez żadnych rabatów, mogą podlegać dodatkowym podatkom i mogą się zmieniać w czasie - więc proszę nie traktować poniższych cen jako ostatecznych ani jako dokładnego przewodnika zakupowego.
Oto ogólny wykres i arkusz XLS z wynikami:

Dla uproszczenia utworzyliśmy kolumnę Operations, która w zasadzie jest sumą Inserts+Updates+Deletes, i użyliśmy jej jako wspólnej metryki wydajności zapisu:

Jak widać, następujące 3 typy instancji są liderami wydajności (z punktu widzenia operacji zapisu Firebirda):
| Instancja | Koszt godzinowy dla Linuxa | Operacje/na sekundę |
|---|
| z1d.xlarge | USD$0.45 | 45834 | | m5dn.2xlarge | USD$0.648 | 45198 | | m5d.2xlarge | USD$0.544 | 44150 |
Co ciekawe, liderzy nie są najdroższymi typami instancji! Oczywiście musimy pamiętać, że test jest jednowątkowy (i nie korzysta z liczby rdzeni) oraz nie wymaga dużej ilości RAM (ponieważ baza danych ma tylko 3,6 GB), ale dla aplikacji, które wymagają szybkiego przetwarzania szczytowych operacji zapisu, te instancje wyglądają naprawdę optymalnie.
Pomimo że te typy instancji nie są najdroższe (wśród testowanych), wciąż są wystarczająco drogie, aby dwa razy pomyśleć o budżecie, a ponieważ jedną z reklamowanych zalet chmury jest elastyczność, warto zacząć od tańszych typów instancji VM, które mogą być wystarczająco dobre do obsługi naszej bazy Firebird, prawda?
Aby znaleźć optymalne typy instancji pod względem kosztów/wydajności, utworzyliśmy kolejną kolumnę w naszym arkuszu: „Operacje za 1 USD”.
To znaczy dokładnie to, co znaczy - ile operacji zapisu można kupić za 1 USD.
Formuła jest następująca:
Operacje_Na_Sekundę * 3600 sekund w godzinie / Cena za godzinę

Jak widać, z tego punktu widzenia liderzy są inni:
| Instancja | Cena godzinowa Linux | Operacje za 1 USD | Operacje na sekundę |
|---|---|---|---|
| c5d.xlarge | USD$0,222 | 579062087 | 35709 |
| c5ad.xlarge | USD$0,2 | 565024995 | 31390 |
| m5dn.xlarge | USD$0,324 | 446037216 | 40143 |
Bardzo interesująca jest pozycja #3, m5dn.xlarge ze szczytową wydajnością ~40K/na sekundę - jest dość blisko lidera wydajności z1d.xlarge z 45834 operacjami/na sekundę, ale znacznie tańsza.
Ogólnie rzecz biorąc, nasze doświadczenie z AWS EC2 pokazuje, że jest to stabilne, dojrzałe środowisko, z wieloma dobrymi funkcjami bezpieczeństwa/kopii zapasowych/wysokiej dostępności itp., ale jak każda złożona platforma wymaga doświadczenia (lub zewnętrznej wiedzy), aby dokonać właściwego wyboru i nie płacić ogromnych rachunków za aplikacje z niezbyt fantastycznym obciążeniem.
Najnowsze wyniki testu INSERT/UPDATE/DELETE
Jak widać, prosty test może być przydatny nie tylko jako porównanie między sprzętem a Firebirdem, ale może też zaoszczędzić kilka dolarów.
Opublikowaliśmy wykres z ostatnio zebranymi wynikami oraz arkusz XLS do zabawy, więc możesz to sprawdzić sam tutaj.
Poniżej znajdują się 3 oczywiste wnioski:
- Dyski NVME naprawdę robią różnicę, więc jeśli potrzebujesz wydajnego serwera Firebird, kup NVME dla baz danych.
- Wysoka częstotliwość CPU jest bardzo ważna dla wysokiej wydajności baz Firebird. Często sprzedawcy namawiają do zakupu procesorów wielordzeniowych z niższą częstotliwością (<3 GHz), ale to może nie być najlepsza opcja dla Firebirda, a mniejsza liczba rdzeni z wyższą częstotliwością może dać lepszy wynik.
- Jeśli profil obciążenia Twojej bazy danych jest mocno zorientowany na zapis, spróbuj zmniejszyć Page Buffers: eksperymentuj z DefaultDbCachePages takimi jak 50K, 100K, 250K itp. Będzie super, jeśli podzielisz się z nami wynikami!
Zachęcamy do analizy wyników testów oraz zadawania pytań lub przesyłania sugestii.
W kolejnych wydaniach „Biuletynu o wydajności Firebirda”
W 2. wydaniu pokażemy, jak skonfigurować kilka instancji SuperClassic do obsługi jednej bazy danych (między innymi może to być przydatne do rozdzielenia obciążenia między kilka portów sieciowych). Plany na kolejne wydania są duże: błędy konfiguracji, testy zaszyfrowanych baz danych, zaawansowane porównanie wydajności Firebird 4 z Firebird 3, optymalizacja indeksów itp.
Jeśli jesteś zainteresowany i chcesz otrzymywać powiadomienia o nowych wydaniach, dołącz do nas na kanale Telegram FirebirdSQL.
Skontaktuj się z nami
Prosimy o kontakt w przypadku pytań i sugestii: Alexey Kovyazin: [email protected].