Цю сторінку перекладено машинним перекладом. Читайте англійський оригінал. English

Бібліотека IBSurgeon

Firebird Performance Newsletter: Issue 1

Ми вирішили запустити більш-менш регулярний «інформаційний бюлетень про продуктивність Firebird», присвячений тестам продуктивності, порадам, хитрощам, покращенню конфігурації тощо.

У першому випуску ми маємо наступне:

Firebird 4 vs Firebird 3: Хороші новини, всі!

З 2019 року, коли ми опублікували першу збірку результатів простого тесту INSERT/UPDATE/DELETE, багато людей надіслали нам результати зі своїх серверів Firebird, і ми додали їх до електронної таблиці та відповідного графіка.

Тест є простим, але потужним інструментом для вимірювання та порівняння продуктивності різних конфігурацій обладнання+Firebird, що дозволяє швидко підтвердити або спростувати проблему з обладнанням чи конфігурацією.

Нещодавно ми використали цей тест для порівняння продуктивності INSERT/UPDATE/DELETE у Firebird 4.0 (версія 4.0.0.2394, кілька збірок з релізу) та 3.0 (версія 3.0.8.33426, знімок, передрелізна версія майбутнього 3.0.8, вона стабільна як мінорний реліз, згідно з автотестами Firebird).

Тестове середовище: Intel i3-10100F 3.60GHz з SSD Samsung SSD 870QVO та RAM-диском (qSoft), з різними обсягами RAM (16, 32, 64) та Page Buffers.

Нижче наведено графік, а ось XLS-таблиця з результатами.

Як ви можете бачити, за однакових умов і з однаковою конфігурацією Firebird 4 приблизно на 10% швидший за 3.0.8 у операціях запису. Це, безумовно, хороші новини і ще один знак, що настав час уважніше придивитися до майбутнього релізу та почати підготовку до міграції.

Звичайно, найкращим підходом буде запустити той самий тест на власному сервері та побачити фактичне покращення самостійно.

Дивіться як це зробити »

Вибір найкращого екземпляра AWS EC2 для максимальної продуктивності запису Firebird

Все більше компаній замислюються про «перехід у хмару», і Amazon Web Service Elastic Cloud є одним із найулюбленіших «хмарних напрямків».

Однак AWS пропонує багато різних типів екземплярів, як обрати найкращий? Звичайно, провести тести!

Ми провели прості тести INSERT/UPDATE/DELETE для 20 типів екземплярів і знайшли кілька дійсно хороших варіантів для Firebird.

Зверніть увагу - всі ціни в розрахунках і графіках нижче вказані для регіону AWS EC2 у Франкфурті, вони взяті як є з aws.amazon.com, без жодних знижок, можуть підлягати додатковим податкам і можуть змінюватися з часом - тому не розглядайте ціни нижче як остаточні або як точний посібник для покупки.

Ось загальний графік та XLS-таблиця з результатами:

Для простоти ми створили стовпець Operations, який по суті є сумою Inserts+Updates+Deletes, і використали його як об’єднаний показник продуктивності запису:

Як ви можете бачити, наступні 3 типи екземплярів є лідерами за продуктивністю (з точки зору операцій запису Firebird):

Екземпляр Погодинна вартість для Linux Операцій/за секунду

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

Цікаво, що лідери не є найдорожчими типами екземплярів! Звичайно, потрібно пам’ятати, що тест є однопотоковим (і не отримує переваг від кількості ядер) і не потребує великого обсягу RAM (оскільки база даних лише 3.6 ГБ), але для застосунків, які потребують швидкої обробки пікових операцій запису, ці екземпляри виглядають дійсно оптимальними.

Незважаючи на те, що ці типи екземплярів не є найдорожчими (серед протестованих), вони все ще достатньо дорогі, щоб двічі подумати про бюджет, і оскільки однією з рекламованих переваг хмари є гнучкість, має сенс почати з дешевших типів віртуальних машин, які можуть бути достатньо хорошими для обслуговування нашої бази даних Firebird, чи не так?

Щоб знайти оптимальні типи екземплярів за співвідношенням ціна/продуктивність, ми створили ще один стовпець у нашій таблиці: «Операцій за 1 USD».

Це означає саме те, що означає - скільки операцій запису ви можете купити за 1 USD.

Формула наступна:

Operations_Per_Second * 3600 секунд у годині / Ціна за годину

Як ви можете бачити, з цієї точки зору лідери інші:

Екземпляр Ціна за годину для Linux Операцій за 1 USD Операцій за секунду
c5d.xlarge USD$0,222 579062087 35709
c5ad.xlarge USD$0,2 565024995 31390
m5dn.xlarge USD$0,324 446037216 40143

Дуже цікавим є #3, m5dn.xlarge з піковою продуктивністю ~40K/за секунду - він досить близький до лідера за продуктивністю z1d.xlarge з 45834 операціями/за секунду, але значно дешевший.

Загалом, наш досвід роботи з AWS EC2 показує, що це стабільне зріле середовище з багатьма хорошими функціями безпеки/резервного копіювання/високої доступності тощо, але, як і будь-яка складна платформа, воно потребує досвіду (або зовнішньої експертизи), щоб зробити правильний вибір і не платити величезні рахунки за застосунки з не фантастичним навантаженням.

Останні результати тесту INSERT/UPDATE/DELETE

Отже, як ви можете бачити, простий тест може бути корисним не лише для порівняння обладнання та Firebird, але й може заощадити вам кілька доларів.

Ми опублікували графік із нещодавно зібраними результатами та XLS-таблицю, щоб ви могли з нею погратися, тож можете перевірити це самостійно тут.

Нижче наведено 3 очевидні висновки:

  1. NVME-диски дійсно вражають, тому якщо вам потрібен потужний сервер Firebird, купуйте NVME для баз даних.
  2. Висока частота процесора дуже важлива для високої продуктивності баз даних Firebird. Часто постачальники штовхають вас купувати багатоядерні процесори з нижчою частотою (<3 ГГц), але це може бути не найкращим варіантом для Firebird, і менше ядер з вищою частотою можуть дати кращий результат.
  3. Якщо профіль навантаження вашої бази даних сильно орієнтований на запис, спробуйте зменшити Page Buffers: проведіть експерименти з DefaultDbCachePages, наприклад 50K, 100K, 250K тощо. Буде чудово, якщо ви поділитеся результатами з нами!

Не соромтеся досліджувати результати тестів і ставте будь-які запитання або надсилайте пропозиції.

У наступних випусках «Інформаційного бюлетеня про продуктивність Firebird»

У 2-му випуску ми покажемо, як налаштувати кілька екземплярів SuperClassic для обслуговування однієї бази даних (серед іншого, це може бути корисно для розподілу навантаження між кількома мережевими портами). Плани на наступні випуски великі: помилки конфігурації, тести зашифрованих баз даних, поглиблене порівняння продуктивності Firebird 4 з Firebird 3, оптимізація індексів тощо.

Якщо ви зацікавлені та хотіли б отримувати сповіщення про нові випуски, приєднуйтесь до нас у FirebirdSQL Telegram Channel.

Зв’яжіться з нами

Будь ласка, зв’яжіться з нами з будь-якими запитаннями та пропозиціями: Alexey Kovyazin: [email protected].