13.12.2009
(c) iBase.ru
В 2006 и 2007 годах мы проводили простые тесты скорости backup (тест1 и тест2). Результаты тестов были не совсем однозначными, например, особенности работы локального протокола на компьютерах с многоядерными процессорами были обнаружены только летом этого года. Также, тесты backup сами по себе достаточно просты, т.к. на скорость резервного копирования оказывает влияние в основном только протокол.
С тестом restore ситуация сложнее, именно поэтому на его подготовку ушло достаточно много времени.
! по мотивам этой статьи был проведен вебинар. Запись вебинара доступна для просмотра и прослушивания.
Restore, в отличие от backup, состоит из нескольких "фаз". При restore сначала сервер создает пустую (новую) базу данных, затем наполняет ее метаданными и данными из резервной копии, и уже в конце создает индексы в базе данных. Таким образом, скорость restore определяется объемом данных и количеством индексов, а также зависит от многих других факторов. Чтобы получить максимальную информацию о происходящих при restore процессах тест состоял из нескольких частей:
В тесте использовался бэкап базы данных 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 на текущий момент)
p.s. поскольку релиз Firebird 2.5 еще не вышел, результаты по нему не являются окончательными, и будут перепроверены после выхода релиза.
Компьютер под управлением Windows XP Prof SP3 32bit и Windows 7 Professional 64 bit.
Размер кластера тома на диске с БД - 16к. Диски (кроме диска с ОС) работают в режиме AHCI.
Дополнительно тестирование под Linux (Suse 11.1 64bit) провел Иван Писаревский. Характеристики используемгого компьютера:
Для теста была написана простая программка, которая выполняла команды gbak по очереди и записывала результат в лог-файлы. Лог-файлы затем были перенесены в файл Excel, по которым сделана сводная таблица, и построены графики. Тесты проводились или по ночам и в нерабочее время, то есть, во время тестов компьютер никак не использовался, и никакие "лишние" программы во время тестов не работали. Тесты выполнялись в следующей последовательности (пакет для одного сервера)
Если во время теста происходил сбой, тест перезапускался повторно (случалось на 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, как для самого быстрого протокола.
Основные выводы из этого графика:
Некоторые подробности раскроются на следющих графиках.
Уже интереснее
Тут становится понятна причина серъезного отставания 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 без индексов. То есть, Firebird 1.5 вставляет данные чуть быстрее остальных версий Firebird, и однозначно быстрее InterBase.
Основной вывод из этого графика - скорость заливки данных с увеличением размера страницы хуже, даже не смотря на то что размер кластера файловой системы 16к.
Для индексов - наоборот, чем больше размер страницы, тем лучше.
Однако, результаты Firebird 1.5 и 2.0 сильно "плавают", даже при повторном выполнении теста. Поэтому было решено не усреднять результаты, а показать данные "как есть".
Тест размера кэша был проведен только на трех серверах. И из графиков видно, что это было оправдано - размер кэша никакого влияния не оказывает на скорость restore как данных, так и на создание индексов. Classic и SuperServer в данном случае показывают абсолютно идентичные результаты, то есть разницы в скорости между этими архитектурами при restore нет.
Понятно, что ни 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 это достаточно однозначный процесс, так что разница в производительности при обычной многопользовательской работе может быть совершенно иной.
Из теста видно, что 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.
Вопросы, замечания и пожелания по тесту просьба присылать на адрес support@ibase.ru.
Также посмотреть и присоединиться к обсуждению теста restore можно на форуме sql.ru.
Доступна запись вебинара по тесту restore, а также файл Excel с результатами и исправленная презентация в PPT.