Эта страница переведена машинным переводом. Читайте английский оригинал. English

Библиотека IBSurgeon

Firebird Performance Newsletter: Issue 1

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

В первом выпуске у нас следующее:

Firebird 4 против 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 ГБ), но для приложений, которым требуется быстро обрабатывать пиковые операции записи, эти экземпляры выглядят действительно оптимальными.

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

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

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

Формула следующая:

Операций_в_секунду * 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, оптимизация индексов и т.д.

Если вы заинтересованы и хотели бы получать уведомления о новых выпусках, присоединяйтесь к нам в Telegram-канале FirebirdSQL.

Свяжитесь с нами

Пожалуйста, свяжитесь с нами по любым вопросам и предложениям: Алексей Ковязин: [email protected].