Parallel.ForEach in action
Imádom, nagyon ügyes dolog. Csak azért nem hajtotta ki jobban a procikat, mert már nem győzték a diszkek.
Érdekes problémaként még az jött elő, hogy több mint 100 szálat indított a Parallel, mert úgy érezte ez jó lesz, de az Sql Server connection poolja alapban max. 100 kapcsolatot engedélyez, így egyes szálak bedugultak. Lejjebb lehet venni a szálak számát, vagy feljebb a poolt. Nekem 80 szál elég volt, úgyse győzte már az SQL Server az adatokat.
January 22nd, 2010 at 2:16 pm
Nem kellemetlen RDP-n at fejleszteni? En biztos kikeszulnek a mellekattintasok miatt…
January 22nd, 2010 at 7:01 pm
Nem abban fejlesztek. A saját laptopomon, aztán berakom a kódot subversionbe, onnan update a szerverre, és ott tesztelem az erőforrásigényes kódokat.
January 26th, 2010 at 4:51 pm
E,
- Szép példája az absztraction leakingnek, hogy nem bírok - akarmennyire is akarok - megszabadulni az alattam lévő erőforrások egyedi vonatkozásaitól (80-as thread limit).
- Nem látom a parallel thread inditási/leállítási overheadet
- Nem látom az f típusát (ez egyébként elépesztően zavar, hogy nekem ugyanúgy ki kell következtetnem, mint a fordítónak. Minek, mikor ott lehetne explicit?)
- Enterprise applikációban a thread tipikusan olyan előforrás, aminek a használatát minimalizálni kell.
Kiváncsi lennék egy olyan görbére, ami a MaxDegreeOfParallelism függvényében mutatja a lefutási időket. Kiváncsi lennek, hol az optimum, szerintem a 80 az nagyon sok.