Тест скорости restore, Firebird и InterBase

(c) iBase.ru, 13.12.2009.

В 2006 и 2007 годах мы проводили простые тесты скорости backup (тест1 и тест2). Результаты тестов были не совсем однозначными, например, особенности работы локального протокола на компьютерах с многоядерными процессорами были обнаружены только летом этого года. Также, тесты backup сами по себе достаточно просты, т. к. на скорость резервного копирования оказывает влияние в основном только протокол.

С тестом restore ситуация сложнее, именно поэтому на его подготовку ушло достаточно много времени.
 
Внимание! По мотивам этой статьи был проведен вебинар. Запись вебинара доступна для просмотра.
 

Что тестируем?

Restore, в отличие от backup, состоит из нескольких "фаз". При restore сначала сервер создает пустую (новую) базу данных, затем наполняет ее метаданными и данными из резервной копии, и уже в конце создает индексы в базе данных. Таким образом, скорость restore определяется объемом данных и количеством индексов, а также зависит от многих других факторов. Чтобы получить максимальную информацию о происходящих при restore процессах тест состоял из нескольких частей:
  1. Сравнение скорости протоколов (tcp, локальный, Services API)
  2. Сравнение скорости заполнения базы данных данными
  3. Сравнение скорости создания индексов
  4. Оценить влияние размера кэша сервера (для SuperServer и Classic)
  5. Оценить влияние размера страницы БД (1, 2, 4, 8 и 16 килобайт), в том числе на скорость заливки данных и создания индексов

В тесте использовался бэкап базы данных 1.5 гигабайт, результирующая база данных имела размер 3.9 гигабайт с индексами, и 3.2 гигабайта без индексов. Индексы в базе занимали 20%, данные – 77%.
 

Кого тестируем?

В тесте приняли участие
  • Firebird 32 bit 1.5.5, 2.0.3.12981, 2.1.4.18220, 2.5.0.25784
  • Firebird 64 bit 2.1.3.18185
  • InterBase 32 bit 2007 и 2009 (с последними SP на текущий момент)
Примечание. Поскольку релиз Firebird 2.5 еще не вышел, результаты по нему не являются окончательными, и будут перепроверены после выхода релиза.
 

Железо и ОС

Компьютер под управлением Windows XP Prof SP3 32bit и Windows 7 Professional 64 bit:
  • MB Gigabyte MA 770-US3 (AMD 770)
  • AMD Phenom II X3 720
  • 4GB RAM
  • Seagate ST3160815AS, 160Gb, SATA II – операционная система
  • Hitachi HDT721064SLA360, 640Gb, SATA II – TEMP и файл Backup
  • Seagate ST31500341AS, 1.5Tb, SATA II – восстанавливаемая из бэкапа база данных
Размер кластера тома на диске с БД – 16к. Диски (кроме диска с ОС) работают в режиме AHCI.

Дополнительно тестирование под Linux (Suse 11.1 64bit) провел Иван Писаревский. Характеристики используемгого компьютера:
  • сервер Proliant DL180G6 с одним 4-ядерным процессором
  • RAD 10 из 3x2 SAS дисков, память контроллера 512Мб
  • 12Gb RAM


Как тестируем?

Для теста была написана простая программка, которая выполняла команды gbak по очереди и записывала результат в лог-файлы. Лог-файлы затем были перенесены в файл Excel, по которым сделана сводная таблица, и построены графики. Тесты проводились или по ночам и в нерабочее время, то есть, во время тестов компьютер никак не использовался, и никакие "лишние" программы во время тестов не работали. Тесты выполнялись в следующей последовательности (пакет для одного сервера):
  • tcp полный restore
  • локальный протокол, полный restore
  • Services API, полный restore
  • tcp, restore без индексов (ключ -i)
  • локальный протокол, без индексов
  • Services API, без индексов
  • -se -page 1024
  • -se -page 2048
  • -se -page 4096 (контрольный замер)
  • -se -page 8192
  • -se -page 16384
  • -se -page 4096 -i (контрольный замер)
  • -se -page 8192 -i
  • -se -page 16384 -i
Если во время теста происходил сбой, тест перезапускался повторно (случалось на Firebird 1.5). Если один из результатов сильно отличался от остальных, или не соответствовал контрольному замеру, тест запускался повторно. В итоге, по каждому серверу тест выполнялся от 2 до 4 раз.
 

Результаты теста

Для начала, чтобы не утруждать вас просмотром всех графиков по частям, приведу общий результат на Windows 32 bit и 64 bit, по всем версиям серверов:



Шкала слева – время в минутах, т. е. суммарное время выполнения всех тестов для каждого сервера. Всего тест занял чистого времени не менее 100 часов.

Теперь рассмотрим тесты по отдельности, с комментариями по каждому тесту.


Скорость протоколов



Из теста видно, что, как и в тестах backup, восстановление через Services API самое быстрое. В среднем tcp медленнее Services API в 5.7 раз, а локальный протокол медленнее Services API в 2.2 раза.

Поскольку разница между протоколами у всех серверов примерно пропорциональна, дальнейшее тестирование производилось только для Sevices API, как для самого быстрого протокола.
 

Полный restore, Services API



Основные выводы из этого графика:
  • InterBase 2007 и 2009 по скорости эквивалентны Firebird 2.5
  • Firebird 2.0 пока по неясным причинам хуже 1.5
  • в Firebird 2.1 изменения кода сделали его самым быстрым на данный момент
  • Firebird 2.5 немного медленнее, чем 2.1
Некоторые подробности раскроются на следющих графиках.
 

Restore без индексов



Уже интереснее:
  • InterBase 2007 и 2009 по скорости вставки данных медленнее всех, даже Firebird 1.5
  • Firebird 2.0 и 2.1 по скорости вставки одинаковы, и быстрее Firebird 1.5
  • Firebird 2.5 медленнее, чем Firebird 2.1
 

Создание индексов



Тут становится понятна причина серъезного отставания Firebird 2.0, а также "одинаковость" InterBase с Firebird 2.5. Причем, чем больше будет индексов в базе данных, тем хуже будут суммарные результаты у Firebird 1.5 и 2.0.

Скорость создания индексов это одновременно и индикатор производительности подсистемы сортировки (при PLAN SORT у запросов).
 

Влияние размера страницы



Firebird 2.0 и выше игнорируют размер страницы 1024 и 2048 байт и автоматически используют минимально разрешенный в этих версиях размер страницы 4096 байт. Поэтому результаты для 1024 и 2048 для этих серверов можно считать контрольными.

Для Firebird 1.5 и InterBase 2007/2009 при размерах страницы 1024 и 2048 наблюдалось чтение из базы данных в момент заливки данных, причем на уровне ~4.5 мегабайт в секунду. Скорее всего это особенность файловой системы (NTFS), размер кластера которой был 16к, однако странно, что ничего подобного для страниц размером 4к и 8к не наблюдалось.


Restore без индексов, размеры страниц



Подтверждение первого графика с Restore без индексов. То есть, Firebird 1.5 вставляет данные чуть быстрее остальных версий Firebird, и однозначно быстрее InterBase.

Основной вывод из этого графика – скорость заливки данных с увеличением размера страницы хуже, даже не смотря на то что размер кластера файловой системы 16к.


Создание индексов, размеры страниц



Для индексов – наоборот, чем больше размер страницы, тем лучше.

Однако, результаты Firebird 1.5 и 2.0 сильно "плавают", даже при повторном выполнении теста. Поэтому было решено не усреднять результаты, а показать данные "как есть".
 

Влияние размера кэша



Тест размера кэша был проведен только на трех серверах. И из графиков видно, что это было оправдано – размер кэша никакого влияния не оказывает на скорость restore как данных, так и на создание индексов. Classic и SuperServer в данном случае показывают абсолютно идентичные результаты, то есть разницы в скорости между этими архитектурами при restore нет.


Windows 7, 64 bit

Понятно, что ни Windows XP, ни Windows 7 не являются серверными платформами, и отличаются по производительности. Однако, проверяя на этих ОС одну и ту же версию Firebird можно понять как разницу между ОС, так и разницу между 32 и 64 битными версиями Firebird.



Здесь видно, что Firebird 2.1 32bit на Windiws 7 64 bit быстрее, чем на Windows XP (на ~14%). Также видна незначительная разница между 32 и 64 битной версиями Firebird.



"Родная" для 64 битной ОС версия Firebird быстрее 32-битной на 12% на вставке данных.



И хоть на графике и одинаковы (32 и 64), при нескольких повторных тестах индексирование 64-битной версией Firebird оказывается на 3-4% хуже, чем 32-битной. Суммарно 64-битный Firebird на 64-разрядной ОС быстрее своего 32-разрядного брата всего лишь на 6%. Учитывайте, что restore это достаточно однозначный процесс, так что разница в производительности при обычной многопользовательской работе может быть совершенно иной.


Тест на Linux



Из теста видно, что tcp очень медленный, а Services API и локальный протокол одинаковы (действительно, локальный протокол на Linux работает как embedded, и равнозначен Services API).

По вставке данных Firebird 1.5 и здесь быстрее Firebird 2.x. Индексы Firebird 1.5 создает медленнее (Firebird 2.0 также чуть медленнее 2.1), но разница не так заметна, как на Windows.

Если вы интересуетесь более подробными графиками, то они есть в результатах теста в Excel на закладке IP Linux.
 

Итог теста

  • Протокол Sevices API быстрее остальных, в разы, поэтому при восстановлении из бэкапа баз данных размером в 1 гигабайт и больше следует использовать только его, чтобы не тратить время зря.
  • Firebird 2.1 на Windows быстрее всех остальных версий Firebird и InterBase.
  • По суммарной скорости restore InterBase 2007 и 2009 и Firebird 2.5 равны.
  • У Firebird 1.5 и 2.0 плохо с созданием индексов и сортировками на диске на Windows.
  • Разрядность Firebird (32 бита и 64) на restore не имеет значимой разницы.
  • Размер кэша БД не имеет никакого влияния на restore.
  • По скорости restore Firebird Classic и SuperServer не отличаются.
Вопросы, замечания и пожелания по тесту просьба присылать на адрес support@ibase.ru.

Также посмотреть и присоединиться к обсуждению теста restore можно на форуме sql.ru.

Доступна запись вебинара по тесту restoreLINK, а также файл Excel с результатами и исправленная презентация в PPT.

Подпишитесь на новости Firebird в России

Подписаться