A Connection Poolról még pár gondolat. Jó, hogy van ez a pool, meg gyorsít is, örülünk neki, főleg webalkalmazásokban. Olyan appokban viszont, ahol állandóan futnak a dolgaink, mint egy asztali alkalmazás esetén, nem biztos, hogy érdemes mohón nyitni-zárni a kapcsolatot.
A tőzsdei kereskedési algoritmusaim backtestje során sok százezer paraméterkombinációt néz végig a gép, próbálja meghatározni a legvalószínűbb nyerési esélyűt vagy legnagyobb profit/szórással rendelkezőt (ennél jóval bonyolultabb a dolog, de ez most nem tőzsdés bejegyzés lesz).
A DAL-t úgy írtam meg ahogy webalkalmazásokban megszoktam, így minden egyes trade mentésénél nyitottam-zártam a connectiont. Profilerrel megnézve kiderült, hogy a pool ellenére is a futási idő harmada az open/close-zal ment el. Emiatt készítettem kétféle SqlHelper osztályt, az egyik állandóan nyitott kapcsolattal működik, a másik az egyéb helyekre nyit-zár mind eddig.
Összegezve, a connection pool kiváló dolog pillanatokra futó alkalmazásokhoz, mint a webalkalmazások, de nem érdemes erőltetni, ha több százezerszer kell nyitni-zárni a kapcsolatot.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
2 COMMENTS
Nekem van egy mini ERP rendszerem, amelynek kliense egy Desktop (Winforms) alkalmazás.
Jó esetben, ha nem fagy le :))), akkor reggel elindítják, este kikapcsolják…
A user napközben a 10-20+ törzstáblát, és millió egyéb listát túr, és viszi fel az új adatokat (megrendelés, számla, partner, stb.).
Vannak bizonyos fő-listák, amelyek automatikusan frissülnek (1-2 percenként), mivel ezek a listák a folyamatok lelkei.
Itt én azt a megoldást alkalmaztam, hogy van 1 kapcsolat amit én kezelek explicite (nem zárom be soha, csak alkalmazás shutdown esetén), és van a “többi” ahol engedélyezve van a pooling.
Ez tulajdonképpen nem más mintha a MinPoolSize-t lőttem be volna a kívánt értékre…
Így lehet spórolni kapcsolat nyitást-csukást. Tehát a legjobb ha felmérjük, hogy mennyi kapcsolatra van szükség, és ennek megfelelően állítjuk be. Persze ekkor meg beszólhat a rendszergazda, hogy minek akarok én annyi kapcsolatot egyszerre…
A fenti alkalmazásban ez nem volt gond, mert kb 10-20 konkurens user volt max, így bőven belefért…
A min pool size önmagában nem segít az sp_resetconnection miatti körülfordulásokon. Márpedig és még egy gépen is interprocessz kommunikáció, lassú.
Az állandóan nyitott konneksön az ok, én is ezt csinálom, csak nem állandóra, hanem a backtest elején megnyitom, pár óráig nyitva marad, majd lezárom.