Hi, многоуважаемый All!
Недавно пришлось провести весьма знаменательный тест ;) По условиям задания
необходимо было
проемулировать быстрый прирост БД и измерить сторость наиболее критичных
участков ...
Одним из основных критериев был поиск цены по прайс-листам и истории
изменения цен ...
Вдаватся в подробности реализации не хотелось бы очень муторное занятие ...
Общий алгоритм таков
ищем вхождения кода товара по таблице TOVAR ищем для них согласно условиям
(CONDITION) поставщиков -
цены (COSTS), выбираем историю (CHANGES) изменения этих цен ...
Процедура поиска - ~200 строк (~12 Кб) включает в себя таблицы, вьюхи, SP,
ветвления, ...
Индексы построены и взяты оптимально везде (процедура вылизывалась не одину
неделю)
Основной цикл идёт по предварительно построенному SQL кот. выполняется через
конструкцию:
for execute statement :sql into .... do
for select ... from conditions into ... do
for select ... from costs into ... do
for select .. from changes into ... do
внутри каждого цикла есть небольшие ветвления и вычисления ...
Итак изначально:
1) Размер БД ~6Gb
2) Таблица TOVAR - 6927739 записей
2) Таблица COSTS - 10370169 записей
3) Таблица CHANGES - 14812665 записей
4) Таблица CONDITION - 7840 записей
После увеличения (нарщивания) обьема:
1) Размер БД ~28Gb
2) Таблица TOVAR - 21638446 записей
2) Таблица COSTS - 44104328 записей
3) Таблица CHANGES - 79023345 записей
4) Таблица CONDITION - 24381 записей
Время выполнения разбито на 4 параметра:
1-й время грязного поиска по полному коду (одна из веток SP)
2-й время грязного поиска по части кода (вторая ветка SP) (starting)
3-й время чистого поиска по полному коду (одна из веток SP)
4-й время чистого поиска по части кода (вторая ветка SP) (starting)
где "чистой" называется замер времени выполнения SP, выполняемой
сразу же за аналогичным поиском ... Сделано что-бы увидеть время
затрачиваемое на ??? наверное на подгрузку индексов, кеша ...
Собственно замеры:
1) Intel PIV (3 Gg), 1 Gb RAM,
80 Gb HDD0 SATA-II (3Gb) [SYSTEM, PAGEFILE, FB-TEMP]
120 Gb HDD1 E-IDE (UDMA-5) [FB-DB2]
320 Gb HDD2 SATA-II (3Gb) [FB-DB1]
Системная шина 800
Замеры изначальной БД:
a) База на HDD2 (SATA-II) б) База на HDD1 (E-IDE)
p1 - 3.242 c. p1 - 3.338 c.
p2 - 3.460 с. p2 - 3.694 с.
p3 - 1.584 c. p3 - 1.610 c.
p4 - 1.732 с. p4 - 1.786 с.
Замеры "увеличенной" БД:
a) База на HDD2 (SATA-II) б) База на HDD1 (E-IDE)
p1 - 3.254 c. p1 - 3.362 c.
p2 - 3.438 с. p2 - 3.654 с.
p3 - 1.560 c. p3 - 1.620 c.
p4 - 1.722 с. p4 - 1.748 с.
2) Duron 700 Mg , 256 Mb RAM,
40 Gb HDD0 E-IDE (UDMA-4) [SYSTEM, PAGEFILE, FB-TEMP]
120 Gb HDD1 E-IDE (UDMA-5) [FB-DB]
Системная шина 133
База на HDD2 (E-IDE)
Замеры изначальной БД: Замеры "увеличенной" БД:
p1 - 5.752 c. p1 - 6.002 c.
p2 - 5.820 с. p2 - 5.764 с.
p3 - 2.436 c. p3 - 2.724 c.
p4 - 2.864 с. p4 - 2.676 с.
Да БД размер страницы = размеру кластера = 32К. перед тестами диски
дефрагментировались, а БД делался
харакире в виде B/R ... Да и ещё перед замерами скорости - для SP, в
той-же транзакции, было сделано
Prepeare ...
Судя по результатам - основное время было потрачено FB на ... разбор самой
SP :( хотя она и была уже
откомпилированна как я понимаю в какое-то подобие байт кода + ей (SP)
сделан prepeare... вемя феча
везде ~0 т.к. итоговая выборка SP не превышала 10-20 записей ...
Время поиска по "увеличенной" БД было чут-ли не меньшим нежели от
изначальной .. что можно обьяснить
лучьшей селективностью индексов, наверное ...
В общем можно было-бы на этом тему и закрыть вроде всё хорошо, но
настораживают факты:
1) время поиска по многолимонным таблицам ПРАКТИЧЕСКИ НЕ ЗАВИСИТ от
скорости HDD !!!???
2) время поиска ПРАКТИЧЕСКИ НЕ ЗАВИСИТ ОТ ПРОЦЕССОРА !!!???
2) время поиска ПРАКТИЧЕСКИ НЕ ЗАВИСИТ ОТ ОБЬЕМА RAM !!!???
3) время поиска ПРАКТИЧЕСКИ НЕ ЗАВИСИТ ОТ ЧАСТОТЫ СИСТЕМНОЙ ШИНЫ !!!???
последние 3 пункта может конечно высосаны из пальца но согласитесь
что PIV 3G и Duron 700Mb сравнивать даже смешно как минимум машины
расходятся на 2 класса и отставание Duron 700 - ки всего на 40 %
выглядит дико особенно если посмотреть на цену одного и другого
компа ...
Остаётся только гадать что-же на самом деле томозит ?
Неужто FB 2.0 виспользовавшаяся тестах или опять виновата Windows XP SP2 ?
PS: Сори за длюнющий пост, просто наболело ...
Реально видно что производительность машин вырастает с каждым
годом в N-й прогрессии а мелкософтовци седают неоптимальными
алгоитмами эту же мощность ещё быстрее и этой гонке никому не
нужных мощностей не видно конца :(
С уважением,
Константин Григорьевич.
===============
