Переход с Interbase на Firebird
Переход с Interbase на Firebird
При переходе с Interbase 7.1 на Firebird 2b возникли проблемы.
Создаю базу, перекидываю данные. При запуске программы - тормоза.
В IB Expert'е подключаю две базы и вижу, что при простом SELECT * FROM table в Firebird 3899 чтений (именно столько записей в таблице), а у Interbase - 1203. Firebird работает три раза медленее!!! Таблицы одинаковые.
Помогите разобраться.
Очень - Очень - Очень сильно жду помощи.
Создаю базу, перекидываю данные. При запуске программы - тормоза.
В IB Expert'е подключаю две базы и вижу, что при простом SELECT * FROM table в Firebird 3899 чтений (именно столько записей в таблице), а у Interbase - 1203. Firebird работает три раза медленее!!! Таблицы одинаковые.
Помогите разобраться.
Очень - Очень - Очень сильно жду помощи.
Последний раз редактировалось S.H.S 25 ноя 2005, 17:58, всего редактировалось 1 раз.
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
Таблица:
CREATE TABLE COMPS (
COMPS_ID INTEGER NOT NULL,
COMPS_NUM INTEGER NOT NULL,
CATEGORY_ID INTEGER,
GOODS_ID INTEGER,
PRICE NUMERIC(5,2),
PRICE_RB INTEGER,
BASE_ID INTEGER,
METKA INTEGER
);
ALTER TABLE COMPS ADD PRIMARY KEY (COMPS_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (GOODS_ID) REFERENCES GOODS (GOODS_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (CATEGORY_ID) REFERENCES CATEGORY (CATEGORY_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (BASE_ID) REFERENCES BASE (BASE_ID);
Простите за "выписки".
Запрос:
SELECT comps_id FROM comps
В Interbase результат:
1302 - non-indexed reads
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 140ms
Avg fetch time = 7,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 31
Writes from cache to disk = 0
Fetches from cache = 3,064
В Firebird результат:
3899 - non-indexed reads
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 151ms
Avg fetch time = 7,55 ms
Current memory = 689,468
Max memory = 727,672
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,974
Меня не столько беспокоит non-indexed сколько разница обращений.
CREATE TABLE COMPS (
COMPS_ID INTEGER NOT NULL,
COMPS_NUM INTEGER NOT NULL,
CATEGORY_ID INTEGER,
GOODS_ID INTEGER,
PRICE NUMERIC(5,2),
PRICE_RB INTEGER,
BASE_ID INTEGER,
METKA INTEGER
);
ALTER TABLE COMPS ADD PRIMARY KEY (COMPS_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (GOODS_ID) REFERENCES GOODS (GOODS_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (CATEGORY_ID) REFERENCES CATEGORY (CATEGORY_ID);
ALTER TABLE COMPS ADD FOREIGN KEY (BASE_ID) REFERENCES BASE (BASE_ID);
Простите за "выписки".
Запрос:
SELECT comps_id FROM comps
В Interbase результат:
1302 - non-indexed reads
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 140ms
Avg fetch time = 7,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 31
Writes from cache to disk = 0
Fetches from cache = 3,064
В Firebird результат:
3899 - non-indexed reads
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 151ms
Avg fetch time = 7,55 ms
Current memory = 689,468
Max memory = 727,672
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,974
Меня не столько беспокоит non-indexed сколько разница обращений.
Re: Переход с Interbase на Firebird
А ты всё сфетчил ? Если фетчить не умеем, сравнивай select count(*)
И где медленнее ? 140 против 150 мс ?
И где медленнее ? 140 против 150 мс ?
select count(*) from comps дал количество там и там 3899 (они естественно одинаковые), также одинаковое количество обращений 3899 (это тоже понятно).
В Interbase:
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 8,358
В Firebird:
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 20ms
Avg fetch time = 20,00 ms
Current memory = 660,560
Max memory = 698,420
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,975
Сразу хочу добавить, что две базы стоят на одном и том же компе. Обращение с одной и той же программы, меняется только в программе имя сервера с *.GDB на *.FDB.
В Interbase:
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 40ms
Avg fetch time = 40,00 ms
Current memory = 9,190,400
Max memory = 9,467,136
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 8,358
В Firebird:
Plan
PLAN (COMPS NATURAL)
Adapted Plan
PLAN (COMPS NATURAL)
------ Performance info ------
Prepare time = 0ms
Execute time = 20ms
Avg fetch time = 20,00 ms
Current memory = 660,560
Max memory = 698,420
Memory buffers = 2,048
Reads from disk to cache = 0
Writes from cache to disk = 6
Fetches from cache = 7,975
Сразу хочу добавить, что две базы стоят на одном и том же компе. Обращение с одной и той же программы, меняется только в программе имя сервера с *.GDB на *.FDB.
Хочешь в чем-нибудь разобраться - спроси об этом умного человека, хоть он тебе не поможет, зато быстрее сам догадаешься.
Всем огромное спасибо.
Кажеться причина в самом Fireberd 2.0 beta. Поставил Fireberd 1.5.3 проблема отпала сама собой. Надеюся, что в 2.0 это чудо только из-за beta-тестирования. Когда оно закончится должно работать все быстрее(Очень на это надеюсь и с нетерпением жду).
Всем огромное спасибо.
Кажеться причина в самом Fireberd 2.0 beta. Поставил Fireberd 1.5.3 проблема отпала сама собой. Надеюся, что в 2.0 это чудо только из-за beta-тестирования. Когда оно закончится должно работать все быстрее(Очень на это надеюсь и с нетерпением жду).
-
- Заслуженный разработчик
- Сообщения: 644
- Зарегистрирован: 15 фев 2005, 11:34
"Ну и наглый ты, Харли" (с)S.H.S писал(а):Кажеться причина в самом Fireberd 2.0 beta. Поставил Fireberd 1.5.3 проблема отпала сама собой. Надеюся, что в 2.0 это чудо только из-за beta-тестирования. Когда оно закончится должно работать все быстрее(Очень на это надеюсь и с нетерпением жду).
Обнаружил потенциальную проблему в Beta, забил на нее болт и при этом хочешь, чтобы в релизе эту проблему устранили? Ню-ню.
Пока ты не сделал ничего, чтобы хотя бы доказать наличие проблемы окружающим. Приведенные примеры не стоят вообще ничего, к сожалению.
Очень простой пример:
Скачиваем и ставим FB 1.5.3. Создаем таблицу с 2-3 полями и одним PK. Забиваем ее данными 10 000 записей. Затем в IB Expert'e запускаем запрос SELECT field_id FROM table. Видим что при количестве записей 10 000 количество обращений около 500-3000 (думаю это цифра зависит от структуры таблицы).
А теперь скачиваем и ставим FB 2.0 Alpha или Beta (я и то и то ставил). Проделываем все тоже самое. Видим - при том же количестве записей количество обращений ровно 10 000.
На одной таблице разница по времени будет в мс, а для большего эффекта создим 2-3 таблицы, с внешним ключем. И напишем что-то вроди SELECT * FROM tabel1 t1, table2 t2, tabel3 t3 WHERE t1.field_id1=t2.field_id1 AND t2.field_id2=t3.field_id2. Заразница во времени между FB 1.5.3 и FB 2.0 будет в несколько секунд.
Вообще я думаю, что это не ошибка, а просто ограничение Beta-версии (по крайней мере очень надеюсь).
Скачиваем и ставим FB 1.5.3. Создаем таблицу с 2-3 полями и одним PK. Забиваем ее данными 10 000 записей. Затем в IB Expert'e запускаем запрос SELECT field_id FROM table. Видим что при количестве записей 10 000 количество обращений около 500-3000 (думаю это цифра зависит от структуры таблицы).
А теперь скачиваем и ставим FB 2.0 Alpha или Beta (я и то и то ставил). Проделываем все тоже самое. Видим - при том же количестве записей количество обращений ровно 10 000.
На одной таблице разница по времени будет в мс, а для большего эффекта создим 2-3 таблицы, с внешним ключем. И напишем что-то вроди SELECT * FROM tabel1 t1, table2 t2, tabel3 t3 WHERE t1.field_id1=t2.field_id1 AND t2.field_id2=t3.field_id2. Заразница во времени между FB 1.5.3 и FB 2.0 будет в несколько секунд.
Вообще я думаю, что это не ошибка, а просто ограничение Beta-версии (по крайней мере очень надеюсь).
Ты подключаешься по локальному протоколу. У которого в 1.5 не было буферизации записей на клиенте. След-но, читалось только то, что отфетчил сам. В 2.0 локальный протокол кладет записи себе за щеку, как и сетевой, отсюда и разница. Проверь на коннекте через localhost и у тебя будут одинаковые цифры на обоих серверах.
Наверное, эту фичу стоит отключить дял XNET. Влад, как считаешь?
ЗЫ. ура моему телепатическому локатору.
Наверное, эту фичу стоит отключить дял XNET. Влад, как считаешь?
ЗЫ. ура моему телепатическому локатору.
Для полной ясности я, наверное, поясню с чего все началось. Я написал программу которая успешно наботала уже больше года, на Delphi под Interbase 7.1. Но мне надоело извращаться с запросами, изобретать велосипед (типа FIRST или CASE). На 7.5 перейти я не решался и выбрал FB 2.0 с его (IIF и другими прелестями). Поменял только сервер и клиент, и, естественно пересоздал базу (точную копию). В программе даже менять ничего не пришлось. Все это проделывал через LOCALHOST. Проверив работу остался доволен. Поставил программу в сеть. Все как бы хорошо, только в одном месте, где связь двух больших таблиц и одной не очень, упала в раз 50. Вернулся на свой комп, где локальный сервер, стуация таже. Дня 4 все мучались с этой задержкой в 4 сек. Затем поставил FB 1.5.3, все стало на много быстрее. НО Я ХОЧУ "IIF".
Если дело в настройках firebird.conf то подскажите - попробую.
Если дело в настройках firebird.conf то подскажите - попробую.
Значится так.
Цифры твои показывают, что в FB ты делаешь полный фетч, а в IB - частичный, отсюда и разница в кол-ве чтений. Это раз.
Запросы со статистикой и планами ты тоже прячешь. Это два.
Как показал ТЛ ДЕ и наша последующая беседа, локальный протокол всегда (?) делает полный фетч. ДЕ сейчас над этим думает. Это три.
Нет никаких ограничений беты. Это четыре.
Если хочешь таки выяснить в чём проблемы - давай сюда
а) тормозящий запрос,
б) DDL таблиц и индексов,
в) статистику индексов,
г)план и статистику его выполнения на IB, FB2 и FB 1.5.3.
Это всё
Цифры твои показывают, что в FB ты делаешь полный фетч, а в IB - частичный, отсюда и разница в кол-ве чтений. Это раз.
Запросы со статистикой и планами ты тоже прячешь. Это два.
Как показал ТЛ ДЕ и наша последующая беседа, локальный протокол всегда (?) делает полный фетч. ДЕ сейчас над этим думает. Это три.
Нет никаких ограничений беты. Это четыре.
Если хочешь таки выяснить в чём проблемы - давай сюда
а) тормозящий запрос,
б) DDL таблиц и индексов,
в) статистику индексов,
г)план и статистику его выполнения на IB, FB2 и FB 1.5.3.
Это всё
Так все таки, что мне где в FB2.0 подкрутить, чтобы количество чтений было примерно одинаковое.
Запросов я не прячу, просто вопрос не в них.
Не хотелось бы показаться полным идиотом, но может кто-нибуди подскажет, где можно почитать про "ФЕТЧ". Или хотя бы в двух словах, что такое полный и частичный фетч, и где это менять (если это возможно).
Запросов я не прячу, просто вопрос не в них.
Не хотелось бы показаться полным идиотом, но может кто-нибуди подскажет, где можно почитать про "ФЕТЧ". Или хотя бы в двух словах, что такое полный и частичный фетч, и где это менять (если это возможно).
давай еще раз уточним:
1. в обоих случаях ты проводишь тест на localhost (НЕ локальный коннект), по tcp, или на удаленном сервере, по tcp. Так?
2. тестируешь в IBExpert, в обоих случаях жмешь
а) кнопку зеленого треугольника при выполнении запроса (выбрать только часть записей, помещающихся в грид)
б) кнопку двойного треугольника (выбрать ВСЕ записи на клиента, сиречь FetchAll).
Fetch - это выборка записей.
1. в обоих случаях ты проводишь тест на localhost (НЕ локальный коннект), по tcp, или на удаленном сервере, по tcp. Так?
2. тестируешь в IBExpert, в обоих случаях жмешь
а) кнопку зеленого треугольника при выполнении запроса (выбрать только часть записей, помещающихся в грид)
б) кнопку двойного треугольника (выбрать ВСЕ записи на клиента, сиречь FetchAll).
Fetch - это выборка записей.