Forum » Programiranje » C# threading
C# threading
urosm ::
Pozdravljeni,
zanima me mnenje, kako ustvariti program, znotraj katerega bom lahko ustvaril npr. 100 (ali 1000) threadov, počakal, da bodo vsi threadi skreirani in jih pognal hkrati.
Poskusil sem s Thread Pool vendar imam občutek, da se ne izvedejo vsi threadi hkrati, ampak nekateri čakajo na prosto mesto v thread pool za izvajanje.
Aplikacija je za testiranje delovanja podatkovnih baz pri 100 (1000) hkratnih uporabnikih.
Vsaka ideja je dobrodošla :)
Lp,
Uroš
p.s.: moj prvi post, upam da nisem kaj zajebal :)
zanima me mnenje, kako ustvariti program, znotraj katerega bom lahko ustvaril npr. 100 (ali 1000) threadov, počakal, da bodo vsi threadi skreirani in jih pognal hkrati.
Poskusil sem s Thread Pool vendar imam občutek, da se ne izvedejo vsi threadi hkrati, ampak nekateri čakajo na prosto mesto v thread pool za izvajanje.
Aplikacija je za testiranje delovanja podatkovnih baz pri 100 (1000) hkratnih uporabnikih.
Vsaka ideja je dobrodošla :)
Lp,
Uroš
p.s.: moj prvi post, upam da nisem kaj zajebal :)
BlueRunner ::
Naredi Event, v vsaki niti se sinhroniziraj na ta objekt, potem ko narediš X instanc niti (ki sedaj vse čakajo na tem objektu), v glavni niti event sproži. Nato pa samo še počakaj na to, da se končajo.
Jean-Paul ::
Niti se tako ali tako izvajajo le navidez sočasno (na enem CPU jedru). Tako da če imaš npr. quad core procesor, se bodo dejansko istočasno lahko izvajale le štiri niti. No, drugače je pri GPU, kjer gre za popolnoma drugo arhitekturo.
BlueRunner ::
Če je proces omejen z I/O, kar delo s podatkovno bazo tipično je, potem vse niti večino časa preživijo v čakanju. Je pa res, da je 1000 niti/jedro pretiravanje, ki bo prej pokazalo omejitev testnega računalnika, kot pa podatkovne baze.
Vsekakor je resen test sestavljen iz mnogo več kot pa 100 niti na enem računalniku.
Vsekakor je resen test sestavljen iz mnogo več kot pa 100 niti na enem računalniku.
Zgodovina sprememb…
- spremenilo: BlueRunner ()
urosm ::
@BlueRunner.. se strinjam, da bi bilo za izvedbo testov uporabiti kakšno farmo računalnikov :) Če mi uspe sinhronizirat iz 4ih bo že uspeh. Glede nitenja... ni šlo, ker kot sta z Jean-Paulom že ugotovila, se niti ne izvedejo potem sočasno, ampak čakajo oz. po defaultu se jih 25 začene sočasno, naslednji pa potem čakajo in iščejo 'prosta' mesta, ki se sprostijo, ko se ena nit zaključi. Nitenje sem zaradi tega opustil in skreiral console app, katero kličem iz main app in sicer tako, da pripravim n procesoc te console app, potem pa vse hkrati poženem.
Glede iz trenutnih meritev je omejitev zaenkrat cpu na strežniku (kjer je baza), pri > 50 'klientih' pa pričakujem tudi kako težavo s cpu-jem iz testnih pc-jev. Kot zanimivost, ram ni zaseden skoraj nič.
Ko bom končal, rezultate seveda objavim :)
Vsi predlogi so seveda dobrodošli.
Lp,
Uroš
Glede iz trenutnih meritev je omejitev zaenkrat cpu na strežniku (kjer je baza), pri > 50 'klientih' pa pričakujem tudi kako težavo s cpu-jem iz testnih pc-jev. Kot zanimivost, ram ni zaseden skoraj nič.
Ko bom končal, rezultate seveda objavim :)
Vsi predlogi so seveda dobrodošli.
Lp,
Uroš
Jean-Paul ::
Kar trdiš, bi veljalo mogoče za user threads. Kernel threads bi se morale obnašati praktično enako kot procesi, s tem da imajo niti manj overheada. Sploh na Windowsih so niti veliko bolj učinkovite kot procesi. No, vsaj včasih je bilo tako.
Mislim, da je bil pri tebi problem v velikosti thread poola. V bistvu sploh ne bi rabil poola, ampak bi pač sam ustvaril toliko niti, kot jih želiš. Kakorkoli že, pretiravati s številom niti nima smisla, ker se kot rečeno izvajajo le navidez sočasno.
lp
Mislim, da je bil pri tebi problem v velikosti thread poola. V bistvu sploh ne bi rabil poola, ampak bi pač sam ustvaril toliko niti, kot jih želiš. Kakorkoli že, pretiravati s številom niti nima smisla, ker se kot rečeno izvajajo le navidez sočasno.
lp
BlueRunner ::
se niti ne izvedejo potem sočasno, ampak čakajo oz. po defaultu se jih 25 začene sočasno, naslednji pa potem čakajo in iščejo 'prosta' mesta, ki se sprostijo, ko se ena nit zaključi.
To je opis za thread pool. Si prepričan, da si uporabil moj predlog?
urosm ::
@Jean-Paul: se strinjam da so niti učinkovitejše kot posamezni procesi. Grem še preverit zakaj mi ni delalo brez thread pool-a.
@BlueRunner: Probaval sem s tvojim predlogom in z thread pool-om. Ne vem točno kaj sem zaj**** pri tvojem načinu, moram preveriti. Program se mi je sesuval pri 200 hkratnih nitih, sumim na problem z SqlConnection driverjem. Opis zgoraj res velja za thread pool.
Z mojim načinom (zagajanje console app in sočasnem pričetku izvajanja) se mi pojavlja problem, da začne pri 100 app-ih nabijati cpu na 100% kar potem (najbrž) pokvari končne rezultate). Sicer ne vem, če bo to pokvarilo končno primerjavo med delovanjem posameznih (različnih) podatkovnih bazah, ker bo isti problem prisoten pri vseh merjenih, tako da bi se do neke mere ta efekt lahko izločil... ne vem, bo potrebno še marsikaj premisliti :/
Lp,
Uroš
@BlueRunner: Probaval sem s tvojim predlogom in z thread pool-om. Ne vem točno kaj sem zaj**** pri tvojem načinu, moram preveriti. Program se mi je sesuval pri 200 hkratnih nitih, sumim na problem z SqlConnection driverjem. Opis zgoraj res velja za thread pool.
Z mojim načinom (zagajanje console app in sočasnem pričetku izvajanja) se mi pojavlja problem, da začne pri 100 app-ih nabijati cpu na 100% kar potem (najbrž) pokvari končne rezultate). Sicer ne vem, če bo to pokvarilo končno primerjavo med delovanjem posameznih (različnih) podatkovnih bazah, ker bo isti problem prisoten pri vseh merjenih, tako da bi se do neke mere ta efekt lahko izločil... ne vem, bo potrebno še marsikaj premisliti :/
Lp,
Uroš
Zgodovina sprememb…
- spremenil: urosm ()
Jean-Paul ::
@Spura: klik klak
@urosm: Malo verjetno, a mogoče je število niti omejeno na nekaj sto. Na Win platformo se sicer ne spoznam najbolje, a tako je bilo včasih na Linuxu, ko smo uporabljali še staro implementacijo niti (LinuxThreads).
@urosm: Malo verjetno, a mogoče je število niti omejeno na nekaj sto. Na Win platformo se sicer ne spoznam najbolje, a tako je bilo včasih na Linuxu, ko smo uporabljali še staro implementacijo niti (LinuxThreads).
Zgodovina sprememb…
- spremenil: Jean-Paul ()
BlueRunner ::
using System; using System.Collections.Generic; using System.Threading; namespace ThreadGo { class Program { private struct ThreadCtx { public ManualResetEvent SyncEvent; public int ThreadId; } static void Main(string[] args) { ManualResetEvent mre; List<Thread> threads = new List<Thread>(); // Create event to start all threads mre = new ManualResetEvent(false); // Create all threads for (int ii = 0; ii < 1000; ii++) { threads.Add(new Thread(Fibonacci)); threads[ii].Start(new ThreadCtx { SyncEvent = mre, ThreadId = ii }); } // Start all threads mre.Set(); // Wait for all threads to finish foreach (Thread t in threads) { t.Join(); } } static void Fibonacci(object state) { int a = 0, b = 1, c; ThreadCtx tc = (ThreadCtx)state; DateTime start, end; // Wait for signal to start tc.SyncEvent.WaitOne(); // Calculate fibonacci start = DateTime.UtcNow; for (int ii = 0; ii < 100; ii++) { c = a + b; a = b; b = c; Thread.Yield(); } end = DateTime.UtcNow; Console.WriteLine("Thread {0} calculated fibonacci from {1} to {2}", tc.ThreadId, start.ToLocalTime(), end.ToLocalTime()); } } }
urosm ::
@arjan_t: nisem niti gledal ostalih orodij ker moram narediti svoje meritve in primerjati SqlConnection, ODBC, ... kateri principi povezovanja so hitrejši, na katere baze itd. Poznaš kako orodje, ki bi mi vse to omogočalo?
Lp,
urosm
Lp,
urosm
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | [JS] AsinhronostOddelek: Programiranje | 1907 (1375) | GupeM |
» | C# threadanje in guiOddelek: Programiranje | 784 (675) | darkolord |
» | AsinhronostOddelek: Programiranje | 2590 (2359) | mihies |
» | lpt light showOddelek: Programiranje | 764 (709) | Looooooka |
» | [JAVA] zaustavitev niti (threadov)Oddelek: Programiranje | 3184 (3184) | morbo |