|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
Добрый день Загружаю в приложение 4000 записей из таблицы с тремя полями типа Blob (В базе на которой проверял поля BLOB SUB_TYPE 1 SEGMENT SIZE 512 CHARACTER SET WIN1251, но если BLOB SUB_TYPE 0 проблема точно такая же). Если экспортировать все данные из таблицы вместе с BLOB в IbExpert в файл, то размер файлов меньше 4.5 Mb. В локальной сети все работает быстро, но если подключаться к Firebird 3.0 через Интернет (ping 23 мсек, MTU не измерял) и выполнять этот же запрос с фетчем всех записей, то время выполнения SQL запроса увеличивается катастрофически Если изменить SQL запрос - преобразовать BLOB на стороне сервера в VARCHAR то работает быстро. Вот так преобразовываю: (cast(cast(onchangescript as blob sub_type 1 character set win1251) as varchar(32000)) as onchangescript) Время выполнения запроса и фетча всех данных (результат запроса загружается в кэш). Проверял в UniDAC, FireDAC и на всякий случай в BDE. Перебирал параметры этих библиотек связанные с BLOB, но так как я фетчу все записи, то улучшить время не получилось. Результаты практически не отличаются: По локальной сети: 0.5 сек c преобразованием в VarСhar: 0.3 сек Через Интернет: 100 сек c преобразованием в VarСhar: 4 сек Смотрел трафик в WireShark, такое ощущение, что при использовании BLOB резко увеличивается количество TCP пакетов и это приводит к падению производительности в 25 раз. Параметр WIRECOMPRESS не уменьшает время выполнения. Вопрос: Это проблема пары fbclient.dll - сервер или компоненты доступа (UniDAC, FireDAC) как то неправильно работают? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 12:00 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
Вадим Мещеряков, нет это особенности работы с типом BLOB. В отличии от других типов блобы при фетче записи не извлекаются сразу а получают только идентификатор блоба. Затем блоб вытаскивается отдельно, для чего нужно минимум 3 сетевых пакета открыть блоб, прочитать сегмент (это может повторится много раз в зависимости от размера), закрыть блоб. Кроме того для VARCHAR есть и другая оптимизация. Обычно когда делается фетч записи, срабатывает префетч и вытаскивается сразу несколько записей, которые помещаются в сетевой пакет и дальнейшие фетчи не требуют сетевых пакетов, пока записи есть в буфере. Для блобов это не работает ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 12:07 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
вот тут я подробности писал 22013340 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 12:11 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
Симонов Денис, Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 12:15 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
Но и компоненты тоже могут вносить свою лепту если они пытаются получить размер блоба перед его вычиткой, например. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 13:34 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
Плохо, что при наличии блоба на странице нет никаких инструментов для его префетча (например, флага какого-нибудь). Много лет назад Бузаджи задавался аналогичным вопросом 3085562 . Вообще в Firebird-е беда с такими строковыми данными, длины которых могут варироваться в широких пределах. Если использовать для этого VARCHAR строки "с запасом", скажем 1000 символов, то таблица пухнет от пустого остатка строки. Если для строки в WIN1251 это не сильно заметно, строка в 1000 символов сожмется до 1000/60=16 байт, то для UTF8 это уже будет в 4 раза больше. А если "запаса" не хватает, и надо больше 2000, 3000, 4000 символов? Тогда большую часть записи будет занимать пустота! Если же использовать BLOB, то тут другие проблемы: проседание скорости фетча на медленных каналах (и компрессия трафика тут как мертвому припарка) и создание версий BLOB-ов при каждом тыке. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2021, 14:19 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
ggreggory то таблица пухнет от пустого остатка строки ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2021, 14:22 |
|
Медленная выполняются SQL с BLOB полями при подключении к серверу по VPN через Интернет
|
|||
---|---|---|---|
#18+
ggreggory, Про длинный varchar. Улучшение алгоритма сжатия записей было отложено, увы. Теперь в этом направлении будет что-то сделано наверное не раньше 5ки. Что касается блобов, то там тоже есть что сделать 1. Можно делать префетч и соединять пакеты open/get_segment хотя бы для чтения первого сегмента для сегментированных блобов 2. Доработать поточные блобы, чтобы seek работал для блобов больше 2Гб 3. В getInfo дать возможность получать длину блобов для блобов больше 2Гб. B кстати getInfo можно было бы соединить с open по крайней мере для определения размера блоба и внести отдельный метод getSize в IBlob. 4. Снять в ODS ограничения на уровни блоба, чтобы можно было хранить блобы больше 32Гб. Вот на это можно забить 5. Дать возможность собирать блобы из строк без создания временных блобов. Уже есть PR с пакетом BLOB_UTILS который позволяет так собирать поточные блобы. Может быть войдёт в 4.1 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2021, 14:47 |
|
|
start [/forum/topic.php?fid=40&fpage=9&tid=1560148]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
69ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 173ms |
0 / 0 |