IBX jak długo może trwać wywołanie procki

Witam

Mam pytanie:

• na formatce IBDatabase, IBTransaction (read commited), IBStoredproc
• w bazie procka TEST, która ma w treści EXIT

Prockę z Delphika wywołuje 100 razy, po zmierzeniu czasu okazuje się że każde wywołanie to około 0.007 s. To dużo czy mało ?

Firebird 2.0.4 (teściłem też na 1.5.2 - to samo), zainstalowany na tej samej maszynie.

Dla mnie to dużo, bo potrzebuje wywoływać bardziej skomplikowaną prockę kilkadziesiąt tysięcy razy, co owocuje długim czekaniem.

//dopisane

Aha, prepare unprepare nic nie zmienia (zresztą jak się tego nie doda to IBX sam to zrobi)

//dopisane 2

Aha, w pierwszym czytaniu commitowałem po każdym wykonaniu ExecProc, jak całość ujmę w jedną transakcję to mam 0.001 ~ 0.002 s czyli dużo szybciej. No tak czy siak w realu commituje co 2000 rekordów. Pytanie czy da się coś więcej wycisnąć niż te 0.002 s ?

//dopisane 3
Eh, w tej rzeczywistej procce jest 65 parametrów. Każdy byłu ustawiany przez ParamByName('NAZWA').AsString := 'zzz' po zamianie na Params[x].AsString uzyskałem zmniejszenie czasu wywołania procki z 0.018 s do 0.006 s <- było o co walczyć (Aha wtedy trzeba parametry zaciągnąć do komponentu). W każdym razie jak macie jeszcze jakieś sposoby na wyciśnięcie z IBStoredProc jakichś dodatkowych zasobów mocy to chętnie wysłucham.

nie możesz tej procki wykonać na całej tabeli, zamiast na kolejnych rekordach? to co często zabiera najwięcej czasu przy bardzo częstym odpytywaniu bazy, to komunikacja program<->baza danych. 65 parametrów to dużo, może część da sie obrobić wewnątrz programu, przepychając mniej danych do bazy? może część parametrów może mieć wartości domyślne? zobacz, czy procedura jest buforowana. czy musisz używać transakcji? nie generuj i nie odbieraj wyników zapytania, jeśli nie musisz.

ŁF napisał(a)

nie możesz tej procki wykonać na całej tabeli, zamiast na kolejnych rekordach?

Odpada to jest import danych z jednego SZDB do drugiego.

ŁF napisał(a)

65 parametrów to dużo, może część da sie obrobić wewnątrz programu, przepychając mniej danych do bazy? może część parametrów może mieć wartości domyślne?

No niestety dużo. Też nic nie poradzę. W zasadzie co by mi te warości domyślne zmieniły ? Jest kilka nieużywanych, ale nie chce ich wycinać, bo mi się mogą przydać w przyszłości, zresztą to tylko kilka z nich.

ŁF napisał(a)

zobacz, czy procedura jest buforowana. czy musisz używać transakcji?

Hmm, no muszę, chyba że Cię źle zrozumiałem. Ale generalnie jawnie rozpoczynam transakcje, i jawnie ją kończę co ~ 2000 przetworzonych rekordów. Chyba że masz na myśil pozostawienie zarządzania transakcjami IBX'om ? Hmmm. Commit co jeden rekord odpada (znacznie wzrasta czas), całym import w jednej transakcji też odpada bo rekordów jest za dużo. Z tego co pamiętam (co prawda na tych tabelach nie próbowałem - zaraz spróbuje) FB zaczyna komsumować sporo pamięci przy dużym logu transakcji. Co masz na myśli pisząc: "... zobacz, czy procedura jest buforowana ..." ?

ŁF napisał(a)

nie generuj i nie odbieraj wyników zapytania, jeśli nie musisz.

Generalnie nie generuje wyników w sensie recordset'a (nauczyłem się tego przy ADO i staram się tego trzymać : )). To są procki "EXECUTABLE" a nie "SELECTABLE". Wynik pobieram przez parametry wyjściowe, a tych jest raptem dwa. Muszę je mieć gdyż stanowią informację o przebiegu importu konkretnego rekordu.

Tak czy siak dzięki za odpowiedź. Zacząłem do tematu podchodzić teraz trochę z innej strony - zastosowałem cache który trochę odciąża procki dostarczając im część gotowych danych. Wyniki są bardzo zadawalające - stosując kilka technik łącznie już mi się udało proces skrócić kilkukrotnie : ) w porównaniu z tym co zastałem. Ale jak masz jeszcze jakieś pomysły to będę bardzo wdzięczny.

Pozdrawiam

po co Ci w ogóle transakcje? nie rozpoczynaj ich, ani nie kończ. skoro to wszystko jedno, czy co rekord, czy co kilka tysięcy, to może w ogóle się bez nich obędzie.
buforowanie procedur - procedura jest kompilowana raz, zostaje w pamięci, w pamięci także pozostają używane indeksy i części tabel. ale to chyba są domyślne ustawienia.

Odpada to jest import danych z jednego SZDB do drugiego.

możesz zaimportować całą bazę, bez jakiejkolwiek obróbki danych, a potem ją przerabiać, w całości wewnątrz drugiej bazy, oszczędzisz olbrzymią ilość czasu zmarnowaną na wyciąganie i wpychanie pojedynczych rekordów.

ŁF napisał(a)

po co Ci w ogóle transakcje? nie rozpoczynaj ich, ani nie kończ. skoro to wszystko jedno, czy co rekord, czy co kilka tysięcy, to może w ogóle się bez nich obędzie.

W zasadzie mi są <ort>w ogóle </ort>nie potrzebne, ale IBX'y tak mają że muszą być powiązane z transakcjami. Jak ja transakcji nie rozpocznę, to niejawnie rozpoczną ją IBX'y. Różnica jest taka, że ja ją świadomie zatwierdzam co 2000 rekordów, a IBX będzie to robił albo co 1 rekord albo wszystko w 1 transakcji.

ŁF napisał(a)

możesz zaimportować całą bazę, bez jakiejkolwiek obróbki danych, a potem ją przerabiać, w całości wewnątrz drugiej bazy, oszczędzisz olbrzymią ilość czasu zmarnowaną na wyciąganie i wpychanie pojedynczych rekordów.

To fakt. Raz już przyjęliśmy częściowo podobne rozwiązanie. No jest to dobry pomysł, jednak trochę kłóci się z przyjętą przez nas technologią, ale to już inny temat.

Dzięki wielkie za pomoc. Zamieniam się już z demona optymalizacji w klepacza kodu. Kilkukrotne przyśpieszenie jest dla mnie zadawalające.