0
Answered

Импорт, почему так долго?

Илья Агафонов 6 years ago • updated by Andrej Repin 6 years ago 8

Мне вот интересно почему так долго? 20 часов импортирует ~16к книг, в дельфевом намного шустрее было...

Answer

Answer
Answered
Три основные причины:
  1. Катастрофическая деградация производительности Firebird базы с увеличением объема
  2. Обновление UI
  3. Маршалинг из Manged в Unmanaged в FirebirdSql драйвере.


1. О производительности Firebird я уже писал:

https://plus.google.com/u/0/117645144499921711425/posts/NLce8cFRfTf
https://plus.google.com/u/0/117645144499921711425/posts/AoRCbSXfcyH

и тут:
https://plus.google.com/u/0/117645144499921711425/posts/Bz8xyoWqu5N

2. Отключение динамического обновления UI возможно даст увеличение производительности на пару процентов.

3. Протокол обмена данными между ADO .NET драйвером и Firebird сервером построен на использовании достаточно больших структур. При каждом запросе к БД происходит заполнение структуры данными в Managed памяти, затем эта структура копируется runtime'ом .NET в Unmanaged память (происходит так называемый маршалинг) и указатель на неё передается дальше в код Firebird'a.

Всё это, в конечном итоге, сказывается на производительности операции импорта.

По поводу базы данных.
  1. Размер странницы рекомендуется выбирать равным размеру кластера в файловой системе. Для NTFS стандартный размер кластера равен 4к (4096)
  2. Флаг "Force Write" заставляет Firebird после каждого изменения в БД скидывать файловые буфера на диск. При этом повышается надёжность, но понижается производительность.
Answer
Answered
Три основные причины:
  1. Катастрофическая деградация производительности Firebird базы с увеличением объема
  2. Обновление UI
  3. Маршалинг из Manged в Unmanaged в FirebirdSql драйвере.


1. О производительности Firebird я уже писал:

https://plus.google.com/u/0/117645144499921711425/posts/NLce8cFRfTf
https://plus.google.com/u/0/117645144499921711425/posts/AoRCbSXfcyH

и тут:
https://plus.google.com/u/0/117645144499921711425/posts/Bz8xyoWqu5N

2. Отключение динамического обновления UI возможно даст увеличение производительности на пару процентов.

3. Протокол обмена данными между ADO .NET драйвером и Firebird сервером построен на использовании достаточно больших структур. При каждом запросе к БД происходит заполнение структуры данными в Managed памяти, затем эта структура копируется runtime'ом .NET в Unmanaged память (происходит так называемый маршалинг) и указатель на неё передается дальше в код Firebird'a.

Всё это, в конечном итоге, сказывается на производительности операции импорта.

По поводу базы данных.
  1. Размер странницы рекомендуется выбирать равным размеру кластера в файловой системе. Для NTFS стандартный размер кластера равен 4к (4096)
  2. Флаг "Force Write" заставляет Firebird после каждого изменения в БД скидывать файловые буфера на диск. При этом повышается надёжность, но понижается производительность.

мда, чем дальше в лес, тем толще партизаны... 1000 книг 1,5 часа, что то не то.
Из предложенных причин первые две я отметаю т.к. они и в дельфевом есть, а вот наличие промежуточного звена в виде ADO и продвинутого алгоритма сравнения книг (причем он часто ошибается, больше 70% ошибок) это сильно тормозит импорт. А без ADO ни как не обойтись? может есть драйвер который напрямую с базой работает?

"Продвинутый" алгоритм сравнения дает не более 3% ошибок, а не 70% как ты пытаешься меня уверить. 70% означало бы, что из твоей тысячи были не правильно распознаны минимум 700 книг, в тестах я этого не наблюдаю и близко.

Да с этим надо что-то делать.

ADO тоже ведь с базой напрямую работает, надо будет подумать о переносе части работы в Native код.

p.s. Второго пункта в старом Библиотекаре нет, Fb2Library умет обновлять списки авторов/серий/книг во время импорта.

p.p.s Возможно скорость можно увеличить обрабатывая книги пачками (хотя бы по 10 штук) в одной транзакции, а не по одной как сейчас.


Ну это смотря что добавлять..
На картинке типичный для меня пример, в файлах бардак, одной книги по 2-3 экземпляра может быть. На скриншоте на самом деле наверное ни одного "Дубликат название отличается" И приходится на первом "Том 3. Алые паруса. Рассказы" кликать "Создать новый документ", а на последующих двух "Обработать повторно" И получаем

Возможно проблема ещё и в кодировке UNICODE_FSS

при импорте найдено 3000 дублей из этих 3-х тысяч книг больше 2500 книги типа
название книги (белорусский язык)=название книги (итальянский язык)
название книги 1750-1760=название книги 1780-1790
и выискивать из этих 3000 именно дубли руками как то меня не прельщает.
А что по поводу ADO?

Это пока единственный существенный недостаток алгоритма. У тебя все книги такие?

достаточно, все это идет из либрусека