[MSDE] Pagina's (ASP) laden extreem traag

[Verwijderd]

Heb onlangs afscheid genomen van Access om de voordelen van MSDE te aanschouwen. Helaas zijn mijn .ASP pagina's die gebruikmaken van een MSDE database extreem traag!

De processor op de server zit tussen de 1 en 5 procent load en het geheugengebruik schommeld rond de 500mb... niet echt spannend dus.

- Een EXEC SP_WHO geeft slechts tussen de 10 en 30 resultaten terug;

En... alle connecties worden altijd netjes afgesloten.

[whoami]

Tja, met deze informatie kunnen we niet veel.

Heb je de SQL Profiler al eens laten draaien, en gekeken welke queries traag zijn ?
Hoe zit het met indexen op je databank ?
Hoe zit het met de statistics van je database ?

[Verwijderd]

Gezien ik een beginner ben in het MSDE (SQL) verhaal zijn de vragen voor mij nog wat onduidelijk

Heb je de SQL Profiler al eens laten draaien, en gekeken welke queries traag zijn ?
SQL Profiler zit toch alleen bij MS SQL en niet bij MSDE?

Hoe zit het met indexen op je databank ?
Hoe bedoel je dit? De tabellen en alles is gemaakt in een Access Project.

Hoe zit het met de statistics van je database ?
Hoe kan ik dezen uitlezen?

Hoewel sommige queries wel wat lang en misschien traag zijn kan het niet zo zijn dat ze zó traag zijn.

[whoami]

SQL Profiler zit bij SQL Server, maar aangezien MSDE dezelfde engine gebruikt, kan je die profiler dus ook gebruiken.

Hoe bedoel ik dit? Ik vraag me af of je wel goede indexen gemaakt hebt op die tabellen ?

Statistieken van je databank kan je updaten door de volgende stored procedure uit te voeren:

code:

sp_updatestats 'resample'

Over hoeveel data spreken we hier trouwens ?

[P_de_B]

Je hebt gelijk dat de profiler alleen bij MS SQL zit, echter als je de evaluatieversie van MS SQL download kun je de clienttools blijven gebruiken, deze werken ook op MSDE. Profiler is echt wel erg handig.

Als er geen indexen op de database zitten (waar het wel een beetje op lijkt) kan een query erg traag zijn in MSDE. Je zult moeten bepalen welke indexen nodig zijn op de database. Om je hierbij te helpen kun je in Query Analyzer (weer een clienttool van MS SQL) het executieplan van de query laten zien. Hier kun je knelpunten analyseren en indexen toevoegen.

[whoami]

En je kan ook de Index Tuning Wizard gebruiken icm een 'workload file' die je de SQL Profiler hebt laten genereren.

[RobIII]

whoami schreef op dinsdag 16 augustus 2005 @ 16:53:
En je kan ook de Index Tuning Wizard gebruiken icm een 'workload file' die je de SQL Profiler hebt laten genereren.

Of gewoon loslaten op een query die je in je query analyzer hebt staan

[Verwijderd]

Hoe bedoel ik dit? Ik vraag me af of je wel goede indexen gemaakt hebt op die tabellen ?

Heb Teratrax Database Manager gedownload en op alle tabellen die veelvuldig worden geraadpleegd een Index op gemaakt. En de database is inderdaad ineens SUPERSNEL! Erg vreemd dat dit zoveel verschil maakt.

De Index heb ik op het unieke veld, Id, gezet. Is dit dan ook een goede index?

Maakt het ook nog uit of de Index Clustered en/of Unique is? En als laatste vraag: wat houdt fill factor en depth in?

[RobIII]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 17:51:
[...]
Erg vreemd dat dit zoveel verschil maakt.

Erg vreemd? Erg vreemd dat je wel met databases aan de slag gaat maar nooit hebt gehoord van indexen lijkt me eerder Indexen zijn er juist om database operaties te versnellen omdat met een index gegevens (lees: records) sneller gevonden kunnen worden. Hence de naam "index". Of loop je ook altijd van voor tot achter door een boek met je vingertje als je een trefwoord zoekt? Persoonlijk sla ik er dan de index liever op na

Verwijderd schreef op dinsdag 16 augustus 2005 @ 17:51:
De Index heb ik op het unieke veld, Id, gezet. Is dit dan ook een goede index?

9 van de 10 keer is het unieke veld (primary key heet zoiets) al indexed en heeft een extra index weinig nut. Verder kunnen we weinig uitspraken hierover doen tenzij je meer info post over je tabellen e.d. (waarbij niet geheel onbelangrijk: onderlinge relaties (dus primary en foreign keys))

Verwijderd schreef op dinsdag 16 augustus 2005 @ 17:51:
Maakt het ook nog uit of de Index Clustered en/of Unique is?

Als de optie er in zit zal het waarschijnlijk wel verschil uit maken he? Lijkt me relatief simpel te googlen of in de helpfiles te vinden wat het verschil is.

Verwijderd schreef op dinsdag 16 augustus 2005 @ 17:51:
En als laatste vraag: wat houdt fill factor en depth in?

Ook dat staat zeker in de helpfiles, en mocht je die niet hebben dan is het prima te googlen.

Maar goed, ik ben de lulligste niet:

Create UNIQUE
Select this option to create a unique constraint or index for the selected database table. Specify whether you are creating a constraint or index by selecting either the Constraint or Index button.

Ignore duplicate key If you create a unique index, you can set this option to ensure each value in an indexed column is unique.

Fill factor
Shows the fill factor that specifies how full each index page can be. If a fill factor is not specified, the database's default fill factor is used. For more information, see Specifying a Fill Factor for an Index.

Pad Index
If you specified a Fill Factor of more than zero percent, and you selected the option to create a unique index, you can tell SQL Server to use the same percentage you specified in Fill Factor as the space to leave open on each interior node. By default, SQL Server sets a two-row index size.

Create as CLUSTERED
Select this option to create a clustered index for the selected database table. For more information, see Creating a Clustered Index.

Creating a Clustered Index
In Microsoft® SQL Server™ databases you can create a clustered index. In a clustered index, the physical order of the rows in the table is the same as the logical (indexed) order of the index key values. A table can contain only one clustered index. UPDATE and DELETE operations are often accelerated by clustered indexes because these operations require large amounts of data to be read. Creating or modifying a clustered index can be time-consuming, because it is during these operations that the table's rows are reorganized on disk.

Consider using a clustered index for:

• Columns that contain a limited number of unique values, such as a state column that contains only 50 unique state codes.
• Queries that return a range of values, using operators such as BETWEEN, >, >=, <, and <=.
• Queries that return large result sets.

To create a clustered index

1. In your database diagram, select the table you want to index, right-click the table, and choose Indexes/Keys from the shortcut menu.
   -or-
   Open the Table Designer for the table you want to index, right-click in the Table Designer, and choose Indexes/Keys from the shortcut menu.
2. Create a new index. For details, see Creating an Index.
   To modify an existing index, select the index from the Selected index list.
3. Select the Create as CLUSTERED check box.

The index is created in the database when you save the table or diagram.

[ Voor 59% gewijzigd door RobIII op 16-08-2005 18:07 ]

[whoami]

Verwijderd schreef op dinsdag 16 augustus 2005 @ 17:51:
[...]


Heb Teratrax Database Manager gedownload en op alle tabellen die veelvuldig worden geraadpleegd een Index op gemaakt. En de database is inderdaad ineens SUPERSNEL! Erg vreemd dat dit zoveel verschil maakt.

Zoals RobIII al zegt, is dat net het doel van indexen.
Een index op een veld, versnelt een zoekopdracht op dat veld. Een INSERT of een UPDATE zorgt dan wel weer voor wat extra overhead (omdat de index moet aangepast worden).

De Index heb ik op het unieke veld, Id, gezet. Is dit dan ook een goede index?

Een index op een primary sleutel is er meestal zowiezo.
Je kan nu ook overwegen om indexen te leggen op velden waar je veelvuldig op zoekt en joined.
Als je veelvuldig gebruikt maakt van een filter op een combinatie van 2 of meer velden, kan je ook een samengestelde index maken op die velden. Dan moet je wel weten dat de volgorde waarin je die velden in de index opneemt, wel eens belangrijk kan zijn.
Als je bv een index hebt op de combinatie (A, B ), en je filtert enkel op A, dan wordt de index gebruikt. Filter je enkel op B, dan wordt de index niet gebruikt.

Maakt het ook nog uit of de Index Clustered en/of Unique is? En als laatste vraag: wat houdt fill factor en depth in?

Dat staat dus in de help.
Als je een 'clustered' index hebt, wil dat zeggen dat die index ook de 'fysieke opslagvolgorde' van je records bepaalt.
Een tabel kan dus slechts één clustered index hebben. Een clustered index kan je leggen op een veld dat je veel gebruikt om te zoeken op 'ranges' (bv. geef me alle records waarvoor veld A tussen vorige week en vandaag ligt). Dit is interessant omdat, als je het éérste record dat binnen die range valt gevonden hebt, je ook zeer snel de andere grens van je range kan vinden. (de index hoeft dan enkel vanaf dat punt verder afgelopen worden).
Aangezien een clustered index dus je 'fysieke opslagvolgorde' bepaalt, leg je dus ook best geen index op een veld dat veel veranderd. Als je dat wel doet, dan wil dat nl. zeggen dat je opslagvolgorde van alle records opnieuw bekeken moet worden als je zo een veld wijzigt. Dat brengt natuurlijk nog meer overhead mee.

[whoami]

Er staat trouwens in de P&W FAQ een mooi stukje over indexen en ook over clustered indexes:
klik

[ Voor 17% gewijzigd door whoami op 16-08-2005 20:31 ]

[Annie]

Voor het geval je deze nog niet in je bezit hebt (geen idee of je deze ook bij msde krijgt): de books online. Onmisbaar als je bezig gaat met mssql.

[ Voor 3% gewijzigd door Annie op 16-08-2005 21:25 ]

[Verwijderd]

Na al jullie tips en commentaar is de database tot vanochtend supersnel geweest en nu valt deze weer terug in zijn oude patroon: traaaaaag .

Mijn tabellenstructuur is vrij simpel:
- menu
- artikel

Eén menuitem heeft meerdere artikelen en daar zit ook een foreign key op (parent en Id).

Heb wel vrij complexe JOINS in mijn SQL code:

code:

SELECT DISTINCT menu.titel, menu.Id, artikelen.parent AS parent_1, min(artikelen.Id)  AS min_Id_1, menu.zindex, artikelen.online  FROM (artikelen  LEFT JOIN menu ON menu.Id=artikelen.parent) WHERE artikelen.online=1   GROUP BY menu.titel, menu.link, menu.Id, artikelen.parent, menu.zindex, artikelen.online   ORDER BY menu.zindex ASC[

Heb voor mijn gevoel de juiste indexes geplaatst en tot gisteravond werkte alles ook supersnel!

[ Voor 35% gewijzigd door Verwijderd op 17-08-2005 18:23 ]

[IJsbeer]

Volgens mij kun je de S achter Join weglaten, er zit er immers maar 1 in

Maar hoeveel records zitten in die tabellen? Enkele tientallen, honderden, duizenden, honderduizenden, miljoenen?
Wat in ieder geval nog een goede optie is, is het gebruik maken van views. SQLServer kan die cachen en als je iedere keer een losse statement naar SQLServer afvuurt dan kan ie dat niet...

[whoami]

Een distinct vertraagd een query natuurlijk wel snel; waarom heb je daar trouwens een distinct nodig, als je al een group by hebt ?

Plak die query eens in Query Analyzer, en bekijk eens het execution plan. Ga na of er table-scans gebeuren, etc...

Heb je een index op artikelen.parent, en op menu.id en menu.zindex ?

_{Verzorg ook eens de layout van die query, zodat men niet de hele tijd naar rechts moet scrollen om die query te bekijken}

SQLServer kan die cachen en als je iedere keer een losse statement naar SQLServer afvuurt dan kan ie dat niet...

Dat kan ie wel. Execution plans van queries kunnen gecached worden als je gebruik maakt van parametrized queries

[ Voor 25% gewijzigd door whoami op 17-08-2005 18:48 ]

[Verwijderd]

Een distinct vertraagd een query natuurlijk wel snel; waarom heb je daar trouwens een distinct nodig, als je al een group by hebt ?

Dat klopt inderdaad, moest de code nog opschonen!

Heb je een index op artikelen.parent, en op menu.id en menu.zindex ?

Ja, daar staat al een index. Heb ook al getest met andere index-combinaties maar ik zie absoluut geen snelheidsverschil meer (zowel positief als negatief).

Een clustered unique index kan ik niet maken omdat mijn tabellen allemaal een AutoNummering veld hebben.

Het probleem is dat het, na het aanmaken van de indexes, supersnel en goed werkte en dat het sinds vandaag echt bagger is...

Misschien toch maar terug naar Access.

- In de tabellen, 12 in totaal waarvan er 10 worden gebruikt voor de website zullen er slechts 2 worden gebruikt die vaak gewijzigd worden en die een stuk of 1.000 records zal bevatten. Ook niet echt spannend lijkt me. Ik heb Access database met 3.000 records waarbij alles zeer goed én snel werkt.

[P_de_B]

Heb je Query Analyzer gedownload? Je kunt dan het Executieplan tonen, misschien kun je die hier eens posten? We kunnen dan precies zien wat er precies zo traag is.

[Verwijderd]

P_de_B schreef op woensdag 17 augustus 2005 @ 20:25:
Heb je Query Analyzer gedownload? Je kunt dan het Executieplan tonen, misschien kun je die hier eens posten? We kunnen dan precies zien wat er precies zo traag is.

Heb wel SQL 2000 Eval gedownload maar die kan ik niet startend krijgen Of moet ik de boel eerst op CD branden en vanaf daar gaan installeren?

Of nog beter: kan ik die Query Analyzer misschien ergens apart downloaden? Want er zijn aardig wat producten die Query Analyzer heten.

---

Maar het lijkt me niet dat het aan langzame queries ligt want eerder (slechts 24 uur geleden) werkte alles nog supersnel en in die tussentijd zijn geen noemenswaardige zaken aan de database toegevoegd / gewijzigd.

---

Resultaat van een Trace met SQL Query Analyzer:
Duration: 240
Cpu: 0
Reads: 211
Writes: 1

---

Zelfs het inloggen in het CMS neemt extreem veel tijd in beslag terwijl hij daarvoor een aparte tabel raadpleegd! Het lijkt me dat er iets anders aan de hand is.

[ Voor 15% gewijzigd door Verwijderd op 17-08-2005 21:48 ]

[whoami]

Verwijderd schreef op woensdag 17 augustus 2005 @ 20:23:
[...]

Een clustered unique index kan ik niet maken omdat mijn tabellen allemaal een AutoNummering veld hebben.

Dat is de reden niet; tenzij er een primary key op die autonummeringsvelden ligt, die je als clustered hebt gecreeërd, maar dat zou in het geval van deze query ook niet echt uitmaken.

Het probleem is dat het, na het aanmaken van de indexes, supersnel en goed werkte en dat het sinds vandaag echt bagger is...

Heb je toevallig een hele hoop data in die database gepompt ?
Zoja, doe dan eens een update van de statistieken (sp_updatestats 'resample').

Over hoe traag spreken we hier trouwens , en hoe snel ging die query eerder ?

[ Voor 6% gewijzigd door whoami op 17-08-2005 21:37 ]

[Verwijderd]

Over hoe traag spreken we hier trouwens , en hoe snel ging die query eerder ?

Het laden van de pagina nam eerder minder dan één seconde in beslag. Tijdens het surfen merkte je niet dat het uit een database werd getrokken. Nu ben ik tussen de 5 en 7 seconden kwijt!

Zoja, doe dan eens een update van de statistieken (sp_updatestats 'resample').

Gedaan en voordat de melding: "Statistics for all tables have been updated" ervoor komt ben ik 23 seconden verder. Het resultaat: nog steeds erg traag.

In de Event Viewer komt steeds deze error:
This SQL Server has been optimized for X concurrent queries. This limit has been exceeded by Y queries and performance may be adversely affected.

[ Voor 54% gewijzigd door Verwijderd op 17-08-2005 22:38 ]

[RobIII]

Verwijderd schreef op woensdag 17 augustus 2005 @ 21:51:
In de Event Viewer komt steeds deze error:
This SQL Server has been optimized for X concurrent queries. This limit has been exceeded by Y queries and performance may be adversely affected.

Met andere woorden: Er lopen meerdere queries tegelijkertijd, en MSDE kan max. 8 concurrent queries verwerken. Dus OF iemand 'zit je site te stangen', of je ASP moet eens goed nagekeken worden.

[whoami]

MSDE is idd 'beperkt' tot een aantal maximum concurrente connecties. In normale omstandigheden zou dit voor een kleine site geen probleem mogen zijn; blijkbaar heb je hier en daar niet netjes geprogrammeerd.

Sluit je je connecties wel allemaal goed af ?
Je moet je connectie pas openen als je ze nodig hebt, en van zodra je geen database-verwerking meer moet doen, die connectie terug sluiten.

MSDE is intended for single user or small workgroup environments. The following are some of the MSDE limitations in comparison with SQL Server:

* No Enterprise Manager
* No Query Analyzer
* No Index Tuning Wizard
* Only 2GB RAM
* Only 2GB database size limit
* Only 2 CPUs
* Only five concurrent batch workloads or 25 concurrent connections for websites
* No Database Server Failover Support
* No Full-text search
* No SQL Server Profiler
* No Import and Export Wizards
* No OLAP
* No English Query
* No SQL Books Online
* No Full or Bulk-Logged recovery model support (only simple)

[ Voor 86% gewijzigd door whoami op 17-08-2005 22:46 ]

[Verwijderd]

Met andere woorden: Er lopen meerdere queries tegelijkertijd, en MSDE kan max. 8 concurrent queries verwerken. Dus OF iemand 'zit je site te stangen', of je ASP moet eens goed nagekeken worden.

Eén webpagina voert inderdaad ongeveer 8 queries uit naar de database voor menuopbouw, gekoppelde artikelen, documenten, headlines, kleurgebruik enz. Maar ná het openen van de connecties sluit ik ze allemaal netjes weer.

Naar mijn idee gaat het niet om het aantal connecties maar het aantal queries wat hij tegelijktijd moet uitvoeren. De kans dat meerdere personen de site bezoeken op hetzelfde tijdstip is natuurlijk ontzettend groot.

Soms is "the limit exceeded by 130 queries...". Het lijkt wel alsof hij de queries 'vasthoud' in het geheugen.

Als een overstap naar MS SQL Server 2000 dit verhelpt dan ga ik dat wel kopen.

[ Voor 3% gewijzigd door Verwijderd op 18-08-2005 15:57 ]

[whoami]

Er kunnen in MSDE blijkbaar 8 concurrente queries lopen zonder performance degradatie.
Hoeveel bezoekers heeft jouw website wel ?
Naar mijn idee moet je toch al een hele hoop bezoekers hebben, wil je hebben dat er meer dan 8 queries echt tegelijk uitgevoerd worden.

[P_de_B]

Verwijderd schreef op donderdag 18 augustus 2005 @ 15:56:
[...]


Eén webpagina voert inderdaad ongeveer 8 queries uit naar de database voor menuopbouw, gekoppelde artikelen, documenten, headlines, kleurgebruik enz. Maar ná het openen van de connecties sluit ik ze allemaal netjes weer.

Naar mijn idee gaat het niet om het aantal connecties maar het aantal queries wat hij tegelijktijd moet uitvoeren. De kans dat meerdere personen de site bezoeken op hetzelfde tijdstip is natuurlijk ontzettend groot.

Soms is "the limit exceeded by 130 queries...". Het lijkt wel alsof hij de queries 'vasthoud' in het geheugen.

Als een overstap naar MS SQL Server 2000 dit verhelpt dan ga ik dat wel kopen.

Kun je eens een voorbeeld van je asp pagina geven? Je moet wel erg veel simultane bezoekers hebben wil je steeds 8 concurrent workloads hebben.

SQL Server 2000 heeft deze beperking niet, maar kost wel 5000 dollar voor een processor license....

[Verwijderd]

whoami schreef op donderdag 18 augustus 2005 @ 16:00:
Er kunnen in MSDE blijkbaar 8 concurrente queries lopen zonder performance degradatie.
Hoeveel bezoekers heeft jouw website wel ?
Naar mijn idee moet je toch al een hele hoop bezoekers hebben, wil je hebben dat er meer dan 8 queries echt tegelijk uitgevoerd worden.

Mijn website heeft op dit moment slechts 10 bezoekers, we zijn hem nu aan het testen en aan het invullen. Toch geeft de Event Viewer vrijwel constant een 'overload' aan van 80 tot 130 queries

Als ik de SQL server agent en de SQL server voor een half uur op stop zet en zet 'm daarna op continue dan is de eerste melding wederom boven de 80 queries.

Een EXEC SP_WHO(2) geeft nog steeds slechts 30 records terug.

(wat is de kans dat iemand de SQL server zit te stangen?)

[ Voor 6% gewijzigd door Verwijderd op 18-08-2005 16:08 ]

[gorgi_19]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:05:
(wat is de kans dat iemand de SQL server zit te stangen?)

Daar heb je profiler voor

[P_de_B]

Je kun hier een trialeditie downloaden. Doe dat even, dan heb je iig goede clienttools ter beschikking.

Het wil er bij mij niet in dat je met 10 bezoekers steeds tegen de limiet van MSDE aanloopt.

[RobIII]

Ik heb het probleem ook met MSDE, maar op die site zitten dan ook 130.000+ users (waarop vaak tot 150+ "tegelijkertijd") en dus way more dan 10... En dan nog krijg ik die melding alleen soms in de "piekuren". Dan is het dus niet zo gek dat je die meldingen (soms!) krijgt. Als je het met 10 bezoekers al hebt doe je toch echt ergens iets fout...

[ Voor 28% gewijzigd door RobIII op 18-08-2005 16:15 ]

[whoami]

P_de_B schreef op donderdag 18 augustus 2005 @ 16:12:


Het wil er bij mij niet in dat je met 10 bezoekers steeds tegen de limiet van MSDE aanloopt.

Bij mij ook niet.
Ik denk dat het te maken zal hebben met het programmeerwerk in die asp pagina.

[Verwijderd]

gorgi_19 schreef op donderdag 18 augustus 2005 @ 16:08:
[...]

Daar heb je profiler voor

Profiler heb ik al! En het lijkt daar niet echt op. Wel een ideale tool trouwens!

RobIII schreef op donderdag 18 augustus 2005 @ 16:12:
Ik heb het probleem ook met MSDE, maar op die site zitten dan ook 130.000+ users (waarop vaak tot 150+ "tegelijkertijd") en dus way more dan 10... En dan nog krijg ik die melding alleen soms in de "piekuren". Dan is het dus niet zo gek dat je die meldingen (soms!) krijgt. Als je het met 10 bezoekers al hebt doe je toch echt ergens iets fout...

Ik doe ook zeker iets fout; en behoorlijk ook! Wist ik alleen maar wat...

whoami schreef op donderdag 18 augustus 2005 @ 16:13:
[...]


Bij mij ook niet.
Ik denk dat het te maken zal hebben met het programmeerwerk in die asp pagina.

Daar dacht ik zelf ook al aan maar alles wordt toch netjes afgesloten na iedere actie. Als het slecht geprogrammeerd zou zijn dan moest ik er toch altijd last van hebben?

[P_de_B]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:20:
[...]
Profiler heb ik al! En het lijkt daar niet echt op. Wel een ideale tool trouwens!


[...]
Ik doe ook zeker iets fout; en behoorlijk ook! Wist ik alleen maar wat...


[...]
Daar dacht ik zelf ook al aan maar alles wordt toch netjes afgesloten na iedere actie. Als het slecht geprogrammeerd zou zijn dan moest ik er toch altijd last van hebben?

Laat eens de asp code zien.

[whoami]

^^ (Alleen relevante aub...)

[cannibal]

heb je ook connection pooling aanstaan? of staat het zo ingesteld, dat voor elke query er een nieuwe wordt aangemaakt? incl. bijbehorende overhead enzo...

[whoami]

Connection pooling staat in SQL Server (en hoogstwaarschijnlijk dus ook bij MSDE) default aan.
Je kan het afzetten in de connection - string, maar dat zal hij waarschijnlijk niet gedaan hebben.

Echter, als die connectie-string niet iedere keer identiek is (een extra spatie is al genoeg), dan zal er geen gebruik kunnen gemaakt worden van connection-pooling

[RobIII]

whoami schreef op donderdag 18 augustus 2005 @ 16:32:
Echter, als die connectie-string niet iedere keer identiek is (een extra spatie is al genoeg), dan zal er geen gebruik kunnen gemaakt worden van connection-pooling

Mythe.
Zie http://www.sql-server-per...nection_pooling_myths.asp, question 1.

[ Voor 15% gewijzigd door RobIII op 18-08-2005 16:34 ]

[P_de_B]

Mja, Connectionpooling is geen issue denk ik, TS loopt tegen de limiet van de 8 concurrent workloads van MSDE aan. Met 10 gebruikers op de site tegen die limiet aanlopen, doet me denken aan niet efficiente asp code.

[RobIII]

P_de_B schreef op donderdag 18 augustus 2005 @ 16:34:
Mja, Connectionpooling is geen issue denk ik, TS loopt tegen de limiet van de 8 concurrent workloads van MSDE aan. Met 10 gebruikers op de site tegen die limiet aanlopen, doet me denken aan niet efficiente asp code.

Of niet-efficiente query's

[pjonk]

De TS zou eens moeten kijken naar disconnected recordsets. Kan een hoop open connecties schelen!
http://www.webpronews.com...sconnectedRecordsets.html

[whoami]

Dat zou ook eerder een workaround zijn ipv een oplossing.

[Verwijderd]

whoami schreef op donderdag 18 augustus 2005 @ 17:17:
Dat zou ook eerder een workaround zijn ipv een oplossing.

Niet persee. Soms kan je voor het opbouwen van een pagina een aardige tijd nodig hebben, en heb je de opgehaalde data over de hele pagina nodig. Als je dan disconnected data gebruikt, blijft de connectie minder lang open staan, dus zal met veel page request het aantal gelijktijdige connecties toch laag blijven.

Nadeel is dat de geheugenbelasting wel groter wordt. Daarnaast is de tijd die het duurt om een pagina op te bouwen vaak dusdanig kort dat de overhead van het disconnected maken van je data met ADO niet opweegt tegen de kortere connectietijd. Kortom, alleen nuttig in specifieke gevallen.

Dit is wel een soort aanvullende mogelijkheid ipv oplossing van het huidige probleem, omdat met disconnected recordsets natuurlijk de connectie alsnog expliciet gesloten moet worden, en aangezien het probleem juist is dat het nu niet goed / overal gebeurt, zal dat probleem eerst structureel opgelost moeten worden.