Temat: Firebird jako server Web
Roman Wilk:
OK,
Opisuje to ponieważ, uważam FB za dobre rozwiązanie i dość często niedoceniane przez środowisko developerów
Poniżej w kilku moim zdaniem najważniejszych zagadnieniach dotyczących zastosowania FB jako serera WEB (w naszym przypdku dedykowanego rozwiązania klasy B2B, B2C zintegrowanego z naszym ERP'em). ERP z LAN ma bliźniaczą baze w Internecie (obydwie bazy to FB), dzięki takiemu rozwiązaniu mamy zapenwnioną 100% kompatybilność danych i praktycznie ich synchronizację w czasie rzeczywistym).
1. Jako server WEB nie może być użyty FB w wersji SuperServer
Dalej będę się upierał, iż mylisz pojęcia...
(nie będę tłumaczył zainteresowanych odsyłam do dokumnetacji), w naszym przypadku bardzo dobrze spisuje się wersja SuperClasic 2.5 postawiona na Debianie (oczywiście http obsługuje Apache)
2. Całość Frameworka strony www i B2B napisane jest w PHP.
3. Baza FB obsługującego WEB jest oczywiście bardzo dobrze zopytmalizowana, niestety FB nie radził sobie w pierwszej wesji w zapytaniami wysyłaymi przez klientów dla czasów odpowiedzi powyżej 100 ms (przytrzymanie klawisza F5 przez 1 min, powodowało, że serwer nie odpowiadał i nie potrafił sam się podnieś). Oczywiście wszystkie zapytania były profilowane i praktycznie indeksy był wykorzystywane we wszystskich wąskich gardłach (mnie samemu szukanie optymalnych indeksów zajęło około tygodnia. Tutaj polecam IBExperta, kawał solidnego narzędzia).
4. Po testach i analizie logiki opartej na zapytaniach wysyłanych przez Klientów, zmieniliśmy zupełnie podejście i zapakowaliśmy co się tylko dało w STORE PROCEDURE (w sumie wyszło ich coś około 300), ale przy takim podejściu FB radzi sobie znakomicie, ustawia w kolejce poszczególne zapytania i praktycznie nie daje się "zabić".
Dziwne by było, gdyby było inaczej...
Ale ciekawi mnie, dlaczego uważasz iż w przypadku zapytań daje się zabić i źle ustawia zapytania w kolejce, a przynajmniej ja to tak rozumiem.
Na pewno dobrze to zrobiliście?
Żadnych problemów z transakcjami, zero zakleszczeń?
Dzięki takiemu podejściu udało się zejść z wykonaniem całego frameworka do około 120 ms. Ale żeby nie było tak różowo w FB wiele poleceń, których można używać w procedurach, niestety nie działa prawidłowo np. CASE ORDER BY :(
Co to znaczy - nie działa?
Podaj przykład - sprawdziłem i mnie tam wszystko działa poprawnie.
a więc tak:
select rh.id,
case rh.sv
when 1 then 'a'
when 2 then 'b'
else 'c'
end as sva
from raporth rh
where rh.d_ta > 0 or rh.d_tnone > 0
order by case rh.sv
when 1 then 'a'
when 2 then 'b'
else 'c'
end desc
jak i tak
select rh.id,
case rh.sv
when 1 then 'a'
when 2 then 'b'
else 'c'
end as sva
from raporth rh
where rh.d_ta > 0 or rh.d_tnone > 0
order by 2 desc
5. "Grzebanie" w firebird.conf dało nam 20 ms następnych oszczędności i tak praktyczne zeszliśmy do 100 ms, w których wykonuj się cały framework.
6. Opytmalizacja synchronizacji ERP'a z B2B dała nam jeszcze trochę rezerwy dla FB (ERP co pewien definiowalny czas (60..600 s) sprawdza stan B2B, czy są nowi Klienci, nowe zamówienia i wiele innych....)
Ps.
Mam nadziej, że to się komuś przyda ... :)
Szczerze? Nie sądzę - za mało konkretów.
Do czego miałoby się to przydać?
Jest tu tylko jeden konkret, że stored procedure działają szybciej od "luźnych" zapytań.
OK, ale to masło maślane - dlaczego tak jest?
Poza tym, wszystko zależy od tego jak te zapytania są pisane - jak luźne zapytania zwracały dane do klienta, które je potem przetwarzał to się nie dziwie, że działa to Wam szybciej jeśli wszystko jest przetwarzane bezpośrednio na serwerze bazy danych.
Ale nie nazwałbym tego jakąś realucyjną zmianą...
Kolejny "konkret" to
"Grzebanie" w firebird.conf dało nam [...] - a konkretnie to o jakie grzebanie chodzi, w jakich parametrach i jakie wartości i dlaczego takie a nie inne?
To mogłoby komuś się przydać, a nie to że procedur jest ok. 300 - to ma być pomocne? Ale w czym?