Új hozzászólás Aktív témák

• #9807 joysefke veterán leslie23 #9798

  Új Válasz 2022-05-23 15:56:19 #9807

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  válasz leslie23 #9798 üzenetére

  Alternatív megoldásként felmerült, hogy a parallel végrehajtásnál csak egy DataSetben tárolnám a lekérdezések eredményeit, majd ezt követően egy külön műveletben sorosan generálnám le az Excel-riportokat.

  Igen, érdemes kódban is elkülöníteni az egymástól nagyon különböző feladatok megvalósítását. Ezzel a hibák kezelését könnyíteni tudod.

  Fogod a Parallel.Forech-edet és ahelyett hogy az abban levő kód (delegate) csinálja a az SQL lekérdezést ÉS az Excel interop hívását:

  A Parallel.Foreach csinálja csak
  -1. az SQL lekérdezést /ahogyan eddig/, az adatok esetleges modellekbe való transzformálását,
  -2. majd az eredmények összefésülését. <= ennek thread safnek kell lennie.

  A 2.-höz használhatsz BlockingCollection<T>-t ami thread safe. A ForEach által futtatott kód az SQL lekérdezés eredményét kiszedi a readerből, opcionálisan áttranszformálja valami modellbe (ez a "T") majd ezt beszúrja a BlockingCollection<T>-be.

  A Parallel.Foreach futása után egyetlen szálon végigiterálsz a A BlockingCollection-ön és feldolgozod a kinyert és összefésült adatokat => meghívod egyenként az Excel interopodat minden egyes adatelemre.

• #9803 sztanozs veterán leslie23 #9798

  Új Válasz 2022-05-23 09:30:22 #9803

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  sztanozs

  veterán

  válasz leslie23 #9798 üzenetére

  COM-ot nem fogsz tudni parallelizálni szerintem, Excel COM csak egy instance-el dolgozik, össze fog akadni biztosan.
  Az adatbázis más kérdés, de ha feldolgozási oldalon van a probléma, akkor nem fogsz nagyobb telejsítményt kisajtolni belőle így sem.

  Amúgy adatbázisban legtöbbször az a gond (INSERT-nél), hogy egyesével viszik fel a rekordokat, így minden utasítás külön tranzakció, és baromi nagy az overhead. Ha fel tudod vinni ezresével, vagy az egészet egszerre, akkor sokkal gyorsabb lesz már ettől is.

• #9800 quailstorm félisten leslie23 #9798

  Új Válasz 2022-05-22 21:36:48 #9800

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  quailstorm

  félisten

  válasz leslie23 #9798 üzenetére

  Arra a timeoutra tudsz valahogy breakpointot tenni, hogy utána parallel stacks-szel megnézd mi a helyzet? Hány lekérdezés van olyankor a sorban és hol tartanak.
  Amikor timeoutol, akkor mennyi timeoutol a 70-ből?

• #9799 martonx veterán leslie23 #9798

  Új Válasz 2022-05-22 21:14:25 #9799

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz leslie23 #9798 üzenetére

  Manapság, amikor a gépeknek van minimum 8GB ramja, szerintem semmi se akadályoz meg abban, hogy ramban tárold, amit csak tudsz. Mi lehet a legrosszabb, ami történik? A winforms appod memória használata felmegy 1-2GB-ig? Na ügy

  Az első kérdésedre elég egyértelmű, hogy mi történik. Ha nincs a connection stringben a timeout beállítva, akkor a default azt hiszem 30s.
  Azt írod, hogy ezek egyenként 5-15 másodpercesek. Igen ám, de nem nehéz belátni, hogy ha ilyen queryből futtatsz 15-öt párhuzamosan, akkor szegény DB szervernek sem 5-15 másodpercébe fog kerülni egyet-egyet végrehajtani, hanem ki tudja mennyivel többe (SQL szerver erőforrásaitól függ). Ergo simán elérheti a 30 másodpercet is 1-1 lekérdezés ideje, és voilá, máris kapod a hiba üzenetet. Legalábbis szerintem ez történik, és ezért is javul meg, amikor connection stringben belefoglalod a korlátlan timeout időt. Vagy egyszerűen csak megölöd a DB-t, és timeout időn belül még új connectiont létrehozni sem sikerül felé.
  Biztos, hogy valami ilyesmi lesz a problémád forrása.

Új hozzászólás Aktív témák