kdv, iBase.ru, 10.03.2007
Проверить скорость backup различными способами и на разных версиях серверов InterBase и Firebird.
Компьютер
Windows XP Professional SP2
AMD Athlon 64 3500+
MB EPOX 9NPA3 Ultra (NForce 4)
2GB RAM
Конфигурация логических дисков сложная, поэтому примем, что
Операционная система находится на физическом диске C: (IDE HDS728080PLAT20)
База данных находится на физическом диске D: (SATA II ST3200827AS)
Бэкап производится на физическом диск E: (SATA HDS728080PLA380)
Все 3 диска (C, D, E) - отдельные физические.
примечание: не смотря на то, что размещение резервной копии (backup) базы на том же физическом носителе где и база данных, грозит в случае повреждения диска потерей и базы и ее резервной копии, одной из целей теста было определить, действительно ли (и насколько) медленнее будет выполняться одна и та же работа на одном или раздельных дисках. Размещение резервной копии и БД на разных логических дисках одного и того же физического диска может дать кажущийся приемлемым результат, но только потому, что обычно скорость обмена с диском не является линейной по его радиусу (как минимум для дисков IDE и SATA).
Firebird 1.5.3, 2.1 (SuperServer), InterBase 7.5.1 sp1, 2007, Yaffil (892).
Утилита gbak, для каждого сервера своя.
Клиентская часть fbclient.dll и gds32.dll также соответствующая версии сервера.
примечание: первоначально в тесте не участвовал Firebird 2.0. По завершении был проверен Firebird 2.0 (release), результат оказался идентичен версии 2.1.0.15036. Yaffil проверялся в том числе и для сборки 884, показав идентичные результаты.
В качестве тестовой базы данных взята БД размером 2.7 гигабайт, содержащая около 150 таблиц и 300 индексов, но в которой только одна таблица является самой большой (14 миллионов записей, 1.9 гигабайт), и 2 поменьше - по 1.5 и 1.1 миллионов записей. База данных не обновлялась после restore, записи на страницах данных расположены максимально плотно.
Размер страницы БД - 16к.
ODS - 10.1
Для каждого сервера в файле конфигурации прописан размер кэша 8192 страниц. В БД одна из таблиц имеет 14 миллионов записей. На всякий случай была проверена скорость backup базы "родного" формата для FB 2.0 и IB 7.5, скорость оказалась идентичной.
Серверы Firebird/InterBase и gbak выполнялись на одном компьютере. Результирующий бэкап имеет размер 2.2 гигабайта.
gbak выполнялся всегда с ключом -g, не смотря на однозначное отсутствие версий записей в базе данных. Аргументы по этому поводу см. в документе.
примечание: дополнительно была попытка протестировать InterBase 6.0.1.0, которая оказалась неуспешной - сервер отказался открывать БД (то ли из-за ODS, то ли из-за размера страницы)
По ходу теста был исключен Firebird 1.5.3 Classic, т.к. оказалось что он не поддерживает Services API и локальный протокол на уровне командной строки (проблема в утилите gbak). При этом, поскольку тест по tcp показал идентичность скорости SuperServer, можно сделать предположение что Классик в данном плане отличаться не будет.
Также, первоначально было проверено влияние ключа -v (полный вывод) на скорость backup. Разница на 6-ти минутах оказалась в 3-4 секунды (относительно gbak без ключа -v), что можно считать несущественным. Таким образом, ключ -v можно считать не влияющим на скорость backup.
Для исключения погрешностей и влияния посторонних факторов тест для каждого сервера проводился как минимум 2 раза, а в некоторых случаях и по 3 раза (при появлении явных отклонений от ожидаемого результата). Всего на тест потрачено примерно 15 часов.
Тест состоял из следующих команд:
Сначала приведем результат только Firebird 1.5.3, т.к. он является наиболее показательным, и даже можно сказать "эталонным". По вертикали - время в минутах и секундах.
Итак, медленнее всех - tcp/ip. На 26% быстрее него - локальный протокол. Еще быстрее (примерно на 48%) - Services API. И, мы видим разницу в 41% между бэкапом через Services API на разных дисках и на одном. Действительно, при backup происходит чтение базы данных и запись файла backup. Разделение этих операций по физическим дискам дает существенную выгоду, даже когда чтением БД и записью бэкапа занимается один и тот же процесс - сервер.
Интересно, что теоретически можно было бы предположить ускорение backup на двухпроцессорных машинах, т.к. в первых двух случаях (localhost и локальный протокол) fbserver.exe и gbak.exe занимают примерно по 45% процессорного времени (см. графики загрузки процессора в конце статьи). Это стоит проверить отдельным тестом, но дальнейшие графики не дают уверенности в возможности подобного ускорения.
Теперь давайте посмотрим детализированный результат по всем версиям серверов, участвовавшим в тесте:
В данном тесте для InterBase 7.5/2007 разницы при backup на разные или один диск не обнаруживается из-за медленного менеджера памяти. Это отнюдь не вывод по результатам теста - наиболее характерно "неспешность" используемого в InterBase менеджера памяти проявляется в других вещах (возможно, об этом будет отдельный тест). Но, как результат, "медленность" менеджера памяти приводит к более высокой загрузке процессора, что ощутимо даже при попытке переключения на другие приложения в момент теста, а также явно видно по PerfMon - загрузка памяти у InterBase в этом тесте всегда 100% без провалов, в то время как у Firebird - на уровне ~95% или меньше.
Давайте посмотрим на графики PerfMon по трем серверам (InterBase 7.5 и 2007 в этом плане идентичны, как вы уже убедились выше. Графики по Yaffil не приведены т.к. идентичны Firebird 1.5, за исключением более высокого disk transfer rate)
| Firebird 1.5 | Firebird 2.1 | InterBase 2007 | |
| localhost |  |
 |
 |
| local |  |
 |
 |
| se |  |
 |
 |
| se 1 hdd |  |
 |
 |
Здесь пурпурным цветом обозначена загрузка процессора процессом fbserver/ibserver (в случае Firebird общая загрузка процессора кроме Services API составляет ~97%, для InterBase - 100% во всех случаях), в % от 100, зеленым цветом - загрузка процессора утилитой gbak, а внизу графика синие, черные и коричневые линии - скорость записи-чтения дисков в мегабайтах. Для локального протокола и tcp это в среднем 5.3 мб/сек, а для Services API - 7.3 мб/сек. У InterBase для Services API скорость дискового ввода-вывода для localhost идентична, для локального протокола и Services API - чуть ниже).
Возвращаясь к менеджеру памяти InterBase - на графиках видно, что одни и те же действия по чтению данных из БД и передаче их утилите gbak в InterBase занимают больше процессорного времени, из-за чего InterBase отстает по результатам. Причем, это же приводит к "недогрузу" жестких дисков и отсутствию различий при использовании одного или разных дисков по чтению/записи.
У Firebird, наоборот, видно (на нижних графиках) что процессора вполне хватает (график загрузки процесора fbserver.exe идентичен общему графику загрузки процессора), однако чтение/запись на одном диске явно ухудшает общий ввод-вывод (относительно графика se). При этом, не смотря на "борьбу" за процессор fbserver и gbak при использовании localhost или локального протокола, на двухпроцессорном компьютере не стоит ожидать прироста в производительности, т.к. процессор все равно "недогружен", например при использовании Services API.
При выполнении backup через Services API gbak или приложение только дает команду на выполнение backup, а дальше сохранением резервной копии занимается только сервер. Таким образом, в отличие от выполнения backup самим gbak (tcp или локальный протокол), в Firebird прекратить выполнение backup можно только путем остановки сервера (в InterBase 7.x/2007 это можно сделать через временные системные таблицы).
В качестве иллюстрации "проблемы" можно привести маловероятный случай, когда вы запускаете backup одновременно 2 или более раз: без -se вы можете снять gbak нажатием Ctrl-C, а при -se - только остановить сервер.
Эту особенность необходимо учитывать, если вас волнует подобный вопрос.
Из теста видно, что в Yaffil существует дополнительная оптимизация (или еще более быстрый менеджер памяти, чем в Firebird), что позволило ему буквально "дать дрозда" остальным участникам. Можно сказать, что для Firebird и InterBase еще есть перспективы ускорения в отношении данного теста.
Следует напомнить, что данный тест - только тест скорости backup, и ничего более. Победа Yaffil в данном тесте не позволяет утверждать, что в интегральном тесте общей производительности он выиграет - как минимум потому, что в Firebird 2.0/2.1 произведены существенные изменения оптимизатора, а общая производительность сервера на реальных системах определяется, по большому счету именно оптимизатором, а иногда и не зависит от версии сервера.
Например, для оценки производительности на всех серверах к базе был выполнен запрос select count(*) по самой большой таблице в БД. Все серверы показали один и тот же результат - 42 секунды, 50% загрузки процессора во время выполнения запроса, и disk transfer rate ~45 мегабайт в секунду (что и является максимумом по вводу-выводу для данного участка диска, где располагалась БД).