отличие скорости выполнения в студио и на сервере
Стоит:
FastReport Server 2.0
FastReport Studio 4.7.5
После миграции БД IBM DB2 с v.8 на v.9 отчет, который работал исправно минут 20 сейчас выполняется до 2ч., но запуская его из Studio скорость осталась прежней ~20мин.
Такая же ситуация и по другим отчетам, но с разной скоростью выполнения, непонятна ситуация почему отчет из под студио выполняется значительно быстрее(2 в 3 раза или на порядок), чем этот же отчет запускаемый с сервера.
На IBM DB2 с v.8 скорости выполнения были сравнимы!
Строка подключения к базt в отчете:
<TfrxADODatabase Name="ADODatabase1" DatabaseName="Provider=IBMDADB2;Password=***;Persist Security Info=True;User ID=vasya;Data Source=FACTORY1;Mode=ReadWrite" LoginPrompt="False" PropData="4545…..
FastReport Server 2.0
FastReport Studio 4.7.5
После миграции БД IBM DB2 с v.8 на v.9 отчет, который работал исправно минут 20 сейчас выполняется до 2ч., но запуская его из Studio скорость осталась прежней ~20мин.
Такая же ситуация и по другим отчетам, но с разной скоростью выполнения, непонятна ситуация почему отчет из под студио выполняется значительно быстрее(2 в 3 раза или на порядок), чем этот же отчет запускаемый с сервера.
На IBM DB2 с v.8 скорости выполнения были сравнимы!
Строка подключения к базt в отчете:
<TfrxADODatabase Name="ADODatabase1" DatabaseName="Provider=IBMDADB2;Password=***;Persist Security Info=True;User ID=vasya;Data Source=FACTORY1;Mode=ReadWrite" LoginPrompt="False" PropData="4545…..
Комментарии
Работа сервера отчетов никак не связана с версией базы - нужно искать корни в миграции. Возможно нужно провести оптимизацию базы данных.
Не выполняется отчет при использовании переменных
В результате долгих экспериментов с оптимизацией выяснилось:
Что если в запросе удалить переменные, а значения записать жестко, то отчет выполняется быстро, так же как и в студио, +0,5-1.сек или на 15% медленнее, если запускать голый запрос в БД.
Это происходит с переменными типа date и string и widestring, c integer проблем нет, но правда не обязательно все переменные тормозят, часть удаляю, часть не удаляю. И часть отчетов, где выборки не большие и есть строковые переменные, работает не быстро, но терпимо.
Но переменные как-то нужны.
А использую их так: переменную задаю не в листе кода, а через список переменных отчета.
Блок VAR не использую. В основном теле кода инициализирую так:
BEGIN
…
Set('Street',''''+''+'''');
…
Затем при запуске окна:
Procedure Page1OnBeforePrint(Sender: TfrxComponent);
Begin
…
Set(' Street ',''''+Edit1.Text+'''');
В запросе пишу : select … where city.street like :S1… , где переменной S1 проставляю свойство widestring/ Street
Стандартная техника, но почему-то отказывается работать, или выполняется после перезагрузки сервера, пока никто не запустил 1-2 отчета, часами.
Тогда меняю принцип задания переменных:
В запросе стираю все свойства по переменной подстановка S1
А в коде даю ей значение через объект как:
SearchStreetQuery.ParamByName('S1').Value := 'Ленина';
Ситуация такая же - висит и вешает других. Кэш растет, а красивый график в Server configurator/Statistic ползет верх до лимита.
Остается одно: формировать строку запроса вставлять в нее переменные как готовые фрагменты и передавать запросу:
SearchStreetQuery.Active:=false;
SearchStreetQuery.SQL.Clear;
SearchStreetQuery.SQL.Text:=memo_sql_begin_part.Text;
ADOQuery1.SQL.Add(<Street>);
SearchStreetQuery.SQL.Text:= SearchStreetQuery.SQL.Text +memo_sql_end_part.Text;
SearchStreetQuery.Active:=true;
А если надо дни обрабатывать, то получается очень много букв:
SearchBornQuery.SQL.Add(CHR(39)+DateToStr(<datebegin>)+ CHR(39)+ ' AND '+ CHR(39)+DateToStr(<dateend>)+ CHR(39) );
Вместо того чтобы просто в запросе прописать:
FROM PERSON P0
WHERE (P0.DATEBORN BETWEEN :B1 AND :B2
В этом варианте отчет работает быстро.
Но хорошо, если переменные идут в конце запроса, типа сортировки, а если это достаточно большой запрос с вложенными подзапросами, куча переменных, то кусочков запроса для сшивания получается много, и отладка встает в час.
Один отчет, куда не шло можно переделать, но переделывать почти все, работающие ранее, слишком затратно.
Что же делать, из-за чего это вдруг такое торможение-повисания.
Сначала казалось, что поля, на которых стоят переменные не проиндексированы, но часть проиндексирована, а часть нет, так же как и в старой базе. И потом причем здесь индексация, с жесткой записью строкового значения, запрос отрабатывается быстро.
Не знаю, что и думать,
Исходя из того, что отчеты с небольшими выборками стали работать медленнее а с большими выборками очень-очень -очень долго, то вывод один: Сервер отчетов подает строку запроса в сервер БД построчно как-то, а не целиком запрос и каждый раз в цикле подачи в базы вычисляет переменную для подстановки.
Или что?
Лечебные свойства калины