Soci (Soczó Zsolt) szakmai blogja

2009.02.23.

.NET teljesítményhangolási tapasztalatok 6.

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.

2 Comments

  1. 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…

    Comment by KRis — 2009.02.23. @ 15:58

  2. 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.

    Comment by Soczó Zsolt — 2009.02.23. @ 16:05

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress