Threading voor database queries

[Verwijderd]

In mijn C# programma wordt bij een methode aanroep een aantal SQL queries achter elkaar uitgevoerd. Afhankelijk van de hoeveelheid data in de database kan het een aantal seconden duren voor alle queries zijn uitgevoerd. Ik ben bezig met het optimaliseren van de SQL queries, maar dat moet je los zien van deze vraag. Ik wil graag weten of naast het optimaliseren het nuttig is om de SQL queries bijvoorbeeld op te delen in twee groepen en die tegelijk in twee threads uit te voeren.

Bij het profilen zie ik vooral dat het lezen van de data (SqlCeReader.Read() & SqlCeCommand.ExecuteScaler()) de meeste tijd vergen. Ook bij het aanroepen van de methode met de taskmanager open zie ik dat de CPU wel piekt, maar niet echt lang hoog blijft steken (P4 2.8 ghz 2 gigabyte). Waarschijnlijk is het een andere factor dan CPU dat zorgt voor de tijdsduur (de harde schijf?). Is threading alleen nuttig bij CPU intensieve operaties of kan het voordeel bieden bij het uitvoeren van SQL queries? Bijvoorbeeld door de queries op te delen in twee groepen en deze tegelijk door middel van twee threads uit te voeren. Databases kunnen immers wel meerdere connecties aan (ook de Sql compact editie die ik gebruik). Maar ik weet niet of in dat geval de performance zou verbeteren als de harde schijf toch de beperkende factor is.

Is het nuttig om in mijn geval meerdere threads op te starten of moet ik dit enkel toepassen voor CPU intensieve operaties? Is het daarnaast nuttig om threading toe te passen voor operaties van een aantal seconden? Een thread kan natuurlijk altijd als het CPU gebruik een probleem wordt.

[ Voor 3% gewijzigd door Verwijderd op 25-12-2007 19:38 ]

[EfBe]

De I/O is veelal een limiterende factor in databases. Dit wordt soms opgelost door de database door data te cachen in memory, maar CE is een dermate gelimiteerde, zinloze database dat ik niet denk dat deze veel cached.

ALS de harddisk je beperkende factor is, dan is iedere 2e connectie zeer vertragend (de stepping van je harddisk kop is de meest vertragende factor in een PC). Ook moet je bedenken dat de database EN jouw programma beiden op de CPU draaien. De een schrijft, de ander leest (in een pipe). Dit houdt in dat wanneer jij er een thread naast gaat opstarten, de andere 2 dus trager werken. Dus alleen wanneer je 4 cores hebt is het wellicht te overwegen.

[whoami]

EfBe, ik geloof dat jij er nu van uit gaat dat de applicatie en de DB op dezelfde computer draaien ? Wat als de DB op een aparte DB - server draait ?
Is het dan niet interessanter om die 2 queries elk in hun eigen thread te laten uitvoeren, ipv ze sequentieel uit te voeren ?

[ Voor 29% gewijzigd door whoami op 26-12-2007 10:52 ]

[Swerfer]

Als je programma niet direct afhankelijk is van de resultaten van de queries, dan zou ik zeker threading toepassen. Je hoeft dan als gebruiker van het programma niet te wachten totdat de queries uitgevoerd zijn om je programma weer te kunnen gebruiken.

Verder als blijkt dat de CPU niet 100% gebruikt wordt, dan kan het zinvol zijn om meerdere queries tegelijk te laten lopen, zolang die queries niet afhankelijk zijn van de volgorde van uitvoering.

[Confusion]

Verwijderd schreef op dinsdag 25 december 2007 @ 19:35:
Is threading alleen nuttig bij CPU intensieve operaties

Threading is juist nuttig bij niet CPU intensieve operaties. Als de CPU al 100% gebruikt wordt, dan heeft een extra thread geen zin.

[EfBe]

whoami schreef op woensdag 26 december 2007 @ 10:51:
EfBe, ik geloof dat jij er nu van uit gaat dat de applicatie en de DB op dezelfde computer draaien ? Wat als de DB op een aparte DB - server draait ?
Is het dan niet interessanter om die 2 queries elk in hun eigen thread te laten uitvoeren, ipv ze sequentieel uit te voeren ?

Hij gebruikt CE Desktop. ALS hij er remote naartoe connect is hij gek CE te gebruiken, hij zou dan Express moeten gebruiken (uberhaupt is Express in 100% van de gevallen de betere keuze, CE is IMHO zelfs brakker dan Access)

[Niemand_Anders]

CE is bedoeld als embedded database. Omdat (xml) datasets nogal traag in gebruik kunnen zijn heem Microsoft een FirebirdSql/sqllite tegenhanger gemaakt welke support voor indexen en enkele simpele functies kent onder de naam Sql Server Compact Edition (SqlCe).

Wil je de database gaan aanspreken als een client/server (multi-tier) systeem, dan zul je toch naar de Express editie moeten gaan kijken.

Omdat SqlCe dus embedded is heeft het weinig nut om parallel een tweede query uit te voeren. De kans is levensgroot aanwezig dat de queries alleen maar langer duren omdat resources gedeelt moeten gaan worden zoals ook aangegeven door EfBe In het geval van SqlCe is het wel belangrijk om regelmatig hierop 'Compact' uit te voeren (anders wordt deze heel erg snel traag).

[Verwijderd]

EfBe, kan je ook onderbouwen op welke manier sql server compact edition gelimiteerd is met betrekking tot performance (als lokale database)? De compact editie heeft voor mij vooral voordeel omdat het makkelijk uit te geven is (enkel een aantal dll bestanden meeleveren).

Voor de rest is het denk ik wel aardig duidelijk: meerdere threads hebben lokaal waarschijnlijk niet zoveel zin.

[ACM]

Confusion schreef op woensdag 26 december 2007 @ 12:08:
Threading is juist nuttig bij niet CPU intensieve operaties. Als de CPU al 100% gebruikt wordt, dan heeft een extra thread geen zin.

Wel als je daardoor meerdere cores kan gebruiken

[Confusion]

ACM schreef op maandag 07 januari 2008 @ 08:58:
Wel als je daardoor meerdere cores kan gebruiken

In het algemene geval is dat natuurlijk zo, maar in de TS werd gesproken over een P4 2.8 GHz.

[EfBe]

Verwijderd schreef op zondag 06 januari 2008 @ 15:31:
EfBe, kan je ook onderbouwen op welke manier sql server compact edition gelimiteerd is met betrekking tot performance (als lokale database)? De compact editie heeft voor mij vooral voordeel omdat het makkelijk uit te geven is (enkel een aantal dll bestanden meeleveren).

Je kunt nu dacht ik met meerdere connecties werken, maar in hoeverre meerdere transacties mogelijk zijn is me vanuit de documentatie niet duidelijk. Het punt is nl. dat de engine van CE nog altijd gebaseerd is op de single-connection engine van CE mobile.

[Swaptor]

Confusion schreef op maandag 07 januari 2008 @ 09:20:
[...]

In het algemene geval is dat natuurlijk zo, maar in de TS werd gesproken over een P4 2.8 GHz.

Als ik me niet vergis zijn er ook P4 2.8's met HT in omloop, dus het zóú kunnen uitmaken wanneer TS er zo een heeft.
Verder wat ACM zegt enzo.

[Voutloos]

Bij HT wil je 2 verschillende taken hebben. Bij 2 dezelfde soorten berekeningen haal je geen winst (mogelijk wel verlies). Maar goed, iedereen snapt inmiddels wel de trend richting meerdere cores.

[ACM]

Confusion schreef op maandag 07 januari 2008 @ 09:20:
In het algemene geval is dat natuurlijk zo, maar in de TS werd gesproken over een P4 2.8 GHz.

Klopt, maar het algemene geval is eigenlijk:

Zodra je met threading meer resources kan benutten, of de bestaande resources beter, dan is het zinvol, anders is het onverstandig. Als je een disk-systeem met meerdere diskheads hebt, dan kan het nuttig zijn om multithreaded data in te lezen als je single-disk-read een bottleneck is maar je cpu's niet. Het is dus per situatie verschillend en er is niet zomaar een algemeen antwoord voor mogelijk.

Met deze single-core P4-situatie kan het dus ook nuttig zijn meerdere threads te gebruiken als dat betekent dat de disk constanter belast wordt en je daardoor dus meer performancer er uit weet te krijgen. Of als er meerdere schijven in een raid-systeem zijn natuurlijk.

Bij CPU-intensieve taken is het inderdaad pas handig als je meerdere cores hebt, want de kans is groot dat je anders door allerlei scheduling en cachemisses slechter af bent.

[lier]

Biedt CE de mogelijkheid om te profilen ?
Waarom duurt het uitvoeren van de query zo lang ?
Heb je de performance counters al gebruikt voor de beperkende factor ?

Verder, kan je aangeven (globaal) waar je mee bezig bent ?
Kan je de queries hier plaatsen ?
Over hoeveel data praat je ?

Als je de queries los draait (zonder C#), hoe lang zijn ze dan bezig ?

[MicroWhale]

om queries te versnellen zijn threads niet de oplossing. We hebben dit een keer getest en de bottleneck bleek niet bij de toevoer te zitten, maar in de database zelf. Wat je zou kunnen doen is een transactie met meerdere queries schrijven. Ook helpt het om (mits mogelijk) de controles te omzeilen die bij de commit plaatsvindt. Bij platte tabellen is dit makkelijk, zeker als je 100% zeker bent van de correctheid van de gegevens.

[AaroN]

ACM schreef op maandag 07 januari 2008 @ 13:13:
[...]

Klopt, maar het algemene geval is eigenlijk:

Zodra je met threading meer resources kan benutten, of de bestaande resources beter, dan is het zinvol, anders is het onverstandig. Als je een disk-systeem met meerdere diskheads hebt, dan kan het nuttig zijn om multithreaded data in te lezen als je single-disk-read een bottleneck is maar je cpu's niet. Het is dus per situatie verschillend en er is niet zomaar een algemeen antwoord voor mogelijk.

Met deze single-core P4-situatie kan het dus ook nuttig zijn meerdere threads te gebruiken als dat betekent dat de disk constanter belast wordt en je daardoor dus meer performancer er uit weet te krijgen. Of als er meerdere schijven in een raid-systeem zijn natuurlijk.

Bij CPU-intensieve taken is het inderdaad pas handig als je meerdere cores hebt, want de kans is groot dat je anders door allerlei scheduling en cachemisses slechter af bent.

Het is zelfs nog simpeler:
Threading zorgt voor een beter gebruik van CPU kracht bij gebruik van blocking I/O calls. Het is dus alleen efficient als je gebruik maakt van I/O. Door threads krijg je dus als het ware van synchrone blocking calls, het effect van asynchrone non-blocking calls, omdat een thread gaat slapen bij een blocking call en weer gewekt wordt bij resultaten.