Сравнение производительности 2.5 и 3.0

asviridenkov
Дата: 10.07.2012 12:16:26
Так как группа на google полумертвая, дублирую еще тут

Вступление
Сделал небольшое сравнение производительности 2.5.2 SS 64 и текущей сборки 3.0 64
Собственно, изначально делалась утилита для оценки производительности серверов под наши задачи (в части сервера БД)
заодно дополнил несколькими тестами для сравнения именно работы версий SQL
Данные тесты проводил на своей машине: Windows 7/64 Core i5 750, 12G RAM, диск SATA WD Black 1Tb

База
Программа (Delphi+FIB) создает БД автоматически, размер страницы 4096, между тестами делается переподсоединение
Коннект локальный, клиент свой для каждого сервера
Тестовая таблица
CREATE TABLE TEST (ID INTEGER NOT NULL,'+
'NAME VARCHAR(255), PRICE DOUBLE PRECISION, IFIELD INTEGER, VARFIELD VARCHAR(3000))

Результаты

1. Тест вставки записей
Производится вставка 100 тыс записей в неиндексированную таблицу
2.5 15669 зап/сек
3.0 13161 зап/сек

Небольшой провал у 3.0

2. Последовательное чтение
Производится запрос select * from test и последующая выборка всех записей
2.5 145560 зап/сек
3.0 139275 зап/сек

Изменения негативные, но незначительные

3. Индексированное чтение
Строится индекс по полю name, затем производится выборка select * from test order by name
2.5 85397 зап/сек
3.0 81103 зап/сек

аналогично - небольшая потеря производительности

4. Подсчет числа записей
select count(*) from test
2.5 909090 зап/сек
3.0 793650 зап/сек
Снова небольшой провал

5. Производительность обмена
Измеряется максимальная скорость обмена запросами с сервером
путем выполнения запроса select 1 from rdb$database
2.5 21276 зап/сек
3.0 21276 зап/сек
Полное совпадение :)

6. Параллельное выполнение
Оценивается способности к параллельному выполнению запросов
Создаются потоки с отдельными подключениями, и в них последовательно выполняются запросы
select * from test order by ifield
Оценивается среднее время выполнение запроса во всех потоках

2.5
threads: 1 avg.time: 1028 msec
threads: 2 avg.time: 2053 msec
threads: 3 avg.time: 3530 msec
threads: 4 avg.time: 4482 msec

3.0
threads: 1 avg.time: 974 msec
threads: 2 avg.time: 1249 msec
threads: 3 avg.time: 1741 msec
threads: 4 avg.time: 2087 msec

Что не может не радовать
У 2.5 распараллеливаемость получилась чуть хуже единицы, а у 3.0 почти дотянула до двойки
Можно еще отметить, что с сортировкой у 3.0 дела чуть лучше

7. Изменения записей
Производится update всех записей таблицы
2.5 18577 зап/сек
3.0 11528 зап/сек
Проигрыш новой версии почти в два раза

8. Удаление записей
Производится delete примерно половины записей таблицы (по условию)
2.5 10506 зап/сек
3.0 9509 зап/сек
Здесь почти без изменений

По просьбам трудящихся выложил сам тест
http://narod.ru/disk/55878555001.79cce6aaf2a0516577636a3f1311c435/FBTest.rar.html

Отзывы и предложения приветствуются
Для работы необходима gds32.dll
kdv
Дата: 10.07.2012 14:03:35
по поводу однопользовательской и многопользовательской производительности Еманов рассказывал на конференции в Люксембурге:
http://www.slideshare.net/mindthebird/review-of-the-firebird-development-in-2011-2012

слайд 12. дальше (вперед и назад) по вкусу.
asviridenkov
Дата: 10.07.2012 14:21:37
Обновил версию
http://narod.ru/disk/55919652001.cc59c3eab7aeadd1a47c2f4956b44ee3/FBTest.rar.html
Теперь с указанием размера страницы, FW, и числа тестовых потоков

Играясь с классиком 2.5.2 заметил резкую деградацию производительности, при превышении потоков над процессорами
На 4-х ядерной машине

Parallels test: threads: 1=1092 msec
Parallels test: threads: 2=1289 msec
Parallels test: threads: 3=1649 msec
Parallels test: threads: 4=1921 msec
Parallels test: threads: 5=6572 msec
Parallels test: threads: 6=13934 msec

При этом, до 4 потоков загрузка процессора растет как положено 25-50-75-100%, а дальше резко падает до 7-15 процентов, с редкими всплесками
Интересно, это у W7 проблема с разбросом процессов или классик дурит?
kdv
Дата: 10.07.2012 14:45:55
когда находишь странности, лучше сравнить
а) с другими версиями
б) 32 vs 64 bit (ФБ)

просто информация о том, что "какие-то потоки деградируют" - не информация вовсе.
asviridenkov
Дата: 10.07.2012 16:00:23
Ну 3.0 64 ведет себя так же, на 32 проверю, но странно если будут отличия

А по поводу "не информация вовсе"
Какая же тогда нужна?
Потоки все одинаковые, выполняют один запрос, потеря скорости очевидна, а проверить может каждый скачав программу
kdv
Дата: 10.07.2012 16:20:52
asviridenkov
А по поводу "не информация вовсе"
Какая же тогда нужна?


например такая:
"Играясь с классиком 2.5.2 заметил резкую деградацию производительности"
относительно чего? 2.1, 2.5.1, 3.0? 32бит или 64 бит?

p.s. кроме того, ты меня обломал с тестом InterBase:
Unsuccessful metadata update.
Key size too big for index A.
asviridenkov
Дата: 10.07.2012 16:34:01
kdv
например такая:
"Играясь с классиком 2.5.2 заметил резкую деградацию производительности"
относительно чего? 2.1, 2.5.1, 3.0? 32бит или 64 бит?


Так в том то и дело, что относительно не чего-то, а здравого смысла
Не должно оно по логике так просаживаться

kdv
p.s. кроме того, ты меня обломал с тестом InterBase:
Unsuccessful metadata update.
Key size too big for index A.


О как, я и забыл уже эти проблемы у IB
Уменьшил до 80 ключевое поле
http://narod.ru/disk/55935143001.fe495a5ae1020c6cc357c3a2ba101596/FBTest.rar.html
kdv
Дата: 10.07.2012 16:42:39
взял пока проверить FB 2.5.2 Classic, 32 bit.
6-ядерный AMD Phenom II 1075T
размер страницы 8к. сетевое соединение (localhost)
FW=ON

4 треда. Явно видно торможение на 4-х.
+
Insert performance:=10338 rec/sec
Read performance:=123152 rec/sec
Indexed read performance:=86580 rec/sec
Count performance:=1052631 rec/sec
Query performance:=15873 queries/sec
Sort time:=1591 msec
Parallels test: threads: 1=1591 msec
Parallels test: threads: 2=1949 msec
Parallels test: threads: 3=2778 msec
Parallels test: threads: 4=11940 msec
Update performance:=26925 rec/sec
Delete performance:=17135 rec/sec


6 тредов, уже на 3-м треде вместо 3 секунд 5 секунд, и на 4-х вместо 12-ти - 18. Есть подозрение что с тестом что-то не то.
+
Insert performance:=10272 rec/sec
Read performance:=120772 rec/sec
Indexed read performance:=87796 rec/sec
Count performance:=1052631 rec/sec
Query performance:=16000 queries/sec
Sort time:=1575 msec
Parallels test: threads: 1=1599 msec
Parallels test: threads: 2=2014 msec
Parallels test: threads: 3=5073 msec
Parallels test: threads: 4=18435 msec
Parallels test: threads: 5=23471 msec
Parallels test: threads: 6=36868 msec
Update performance:=25839 rec/sec
Delete performance:=12565 rec/sec


то же самое, на 2.5.1, 32бит, классик
4 треда. Опять 4-ый сразу тормозит на 6-ти ядрах.
+
Insert performance:=6959 rec/sec
Read performance:=120772 rec/sec
Indexed read performance:=90171 rec/sec
Count performance:=793650 rec/sec
Query performance:=15873 queries/sec
Sort time:=1435 msec
Parallels test: threads: 1=1409 msec
Parallels test: threads: 2=1776 msec
Parallels test: threads: 3=3577 msec
Parallels test: threads: 4=16540 msec
Update performance:=25536 rec/sec
Delete performance:=14697 rec/sec


6 тредов. Точно так же видно что уже на 3-ем треде начинаются тормоза. Что-то явно с тестом.
+
Insert performance:=6990 rec/sec
Read performance:=123152 rec/sec
Indexed read performance:=91491 rec/sec
Count performance:=1052631 rec/sec
Query performance:=14184 queries/sec
Sort time:=1435 msec
Parallels test: threads: 1=1409 msec
Parallels test: threads: 2=1766 msec
Parallels test: threads: 3=4609 msec
Parallels test: threads: 4=16380 msec
Parallels test: threads: 5=21200 msec
Parallels test: threads: 6=37229 msec
Update performance:=26048 rec/sec
Delete performance:=15943 rec/sec


что именно тестируется, я не совсем понимаю, потому что каждый процесс классика в основном пишет, а не читает. Например, очень быстро "записано байт" доходит до 1 гиг, при этом читается не более 370мб, потом плюс еще 1 гиг пишется, и еще 370мб читается. Почему тестируется 70/30 запись к чтению, а не наоборот? Ведь получается, что тест "тестирует" IOPS диска.
kdv
Дата: 10.07.2012 16:45:34
asviridenkov
Не должно оно по логике так просаживаться

см. мой результат. И когда ты пишешь "хуже", пиши что хуже чего, потому что иначе приходится за цифрами прыгать по сообщениям. Я об этом, а не о чем то другом :-)
kdv
Дата: 10.07.2012 16:48:31
С IB тест не идет.
---------------------------
Fbtest
---------------------------
Arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets.
---------------------------
ОК
---------------------------