manglende connection close indfydelse på performance

Hvis du ikke bruger en connection pool (og det mener jeg ikke at ADO gør) så
bør ikke lukkede connectiosn give fejl og ikke dårlig performance.

Du kan teste connections med:
  sp_who
i EM QA eller OSQL.

Vi bruger ADO, men ikke-lukkede connections giver ikke fejl (tror vi) men vi får dårlig performance.

Vi har logget forskelligt under den høje belastning og kan se at der har været nogen "internal Server Error"-fejl , men er det en sådan fejlbesked du forventer ved ikke lukkede connections ?

Er det 0115 fejl I får?

Connections skal lukkes, det er klart, så det må I i gang med.

Problemet findes to steder:

Serveren har brug for at kunne slippe connections hurtigt, ellers vil de eksistere indtil timeout. En rigtig god ting er i øvrigt at Dim'e objekterne:

Dim Con
Set Con = ServerCreateObject("ADODB.Connection")

osv.

MSSQL har også brug for at lukke, især hvis du laver mange Update eller Inserts. Hvis du bruger denne syntaks:

Set Rec = Con.Execute("SELECT ....")

- så har du et problem. Du skal bruge:
Dim Con, Com, Rec
Set Con = ServerCreateObject("ADODB.Connection")
Set Com = Server.CreateObject("ADODB.Command")
Con.Open "ConnectionString her, ok?"
Com.ActiveConnection = Con
Set Rec = Server.CreateObject("ADODB.Recordset")
Com.CommandText = "SELECT ...."
Rec.Open Com, , 0, 1

'hvad du nu vil

Rec.Close
Con.Close
Set Con = Nothing
Set Com = Nothing
Set Rec = Nothing

Parametrene 0 og 1 er hhv CursorType og LockType.

Cursoren bestemmer om du har mulighed for at "bladre tilbage", og om du kan få et RecordCount. Skal du ikke kunne bladre tilbage med Rec.MovePrevious, og skal du ikke bruge et RecordCount, så skal du bruge 0.

Locktype bestemmer om data skal låses indtil du har sluppet dem igen, fordi du vil have lov til at ændre dem. Hvis du ikke skal ændre data, men bare læse dem, skal du bruge 1.

Hvis du vil have alle faciliteter kan du bruge

Rec.Open Com, , 3, 3   

Så behøver du egentlig ikke flere som udgangspunkt.

En anden vigtig grund til performanceproblemer er mangel på indexer. Først og fremmest skal alle tabeller have en Primary Key, og alle felter der bruges som relaterede felter, eller Foreign Keys, skal indexeres

>>ldanielsen
ved en select plejer jeg at gøre således (når jeg husker close)

dim strSQL, objRec, objCon
strSQL = strSQL & "SELECT * from tabel"                        & vbcrlf
Set objRec = Server.CreateObject("ADODB.Recordset")
Set objCon = Server.CreateObject("ADODB.Connection")
objCon.Open strCon
objRec.Open strSQL, objCon, AdOpenStatic, AdLockReadOnly, AdCmdText

if not objRec.eof then
    'noget
end if   

objRec.close
Set objRec = nothing
objCon.close
Set objCon = nothing

ved en insert eller update plejer jeg at gøre således

dim objCon, strSQL
strSQL = "INSERT eller update ..."
Set objCon = Server.CreateObject("ADODB.Connection")
objCon.Open strCon
objcon.execute strSQL
objCon.close
set objCon = nothing

Ser du problemer i dette ?

Jeg er ikke sikker på jeg forstår hvad dit Com objekt gør, Men jeg vil meget gerne lære. Hvis mine flere hundrede inserts og updates skal laves om gør jeg det gerne hvis du kan overbevise mig om at det vil betyde en performance forbedring.

Vi har ladet databasen indexere og MSSQL sagde at det gav 17%, men det hjælper ligesom ikke nok når når svartiderne når op over 10 sekunder.

Det der er vigtigt er at du får sat de mindst resourcekrævende properties på dit Recordset, og det gør du. Det ser helt rigtigt ud.

Ang Command: En Command er det object der indeholder CommandText, dvs din sql, Parameters til brug ved stored procedures, og Commands kan være af forskellig type. Commands er knyttet til en connection med Command.ActiveConnection

Hvis du ikke opretter et Command objekt vil ADO selv lave det når du beder om at "Open" et recordset, eller "Execute" en sql-sætning. ADO vil udfra sammenhængen sætte de korrekte properties, men det er lidt ekstra arbejde for serveren.

Hvis du selv laver en Command kan du styre det præcist, og du vil næsten altid kunne nøjes med én Command på en side, som du så genbruger, i modsætning til de evt. mange der automatisk vil dannes. Endelig kan du sætte dem til Nothing, og således være helt sikker på at resourcerne frigives med det samme. Jeg vil tro at Commands ellers vil få lov til at timeout'e, men er faktisk ikke helt sikker på det.

Jeg ved heller ikke hvor mange resourcer man kan spare, men det er nok marginalt.

I har ladet databasen indexere, det lyder som om I bruger en databasedesigner udefra, eller er det noget software der gør det? Igen, er der Primary Keys på alle tabeller, og Foreign keys de rigtige steder? Det er meget vigtigt, jeg har selv oplevet at en query kører 10 til 20 gange så hurtigt efter at de rigtige indexer blev lavet.

Giv os evt. et eksempel på en proces der varer for længe, og lad os give et bud på hvorfor, og hvilke indexer der burde være.

Det var noget software vi brugte til at indexere databasen på baggrund af workload.

Jeg mener ikke jeg har en eneste tabel uden primary key. Foreign keys bruger jeg ikke da jeg synes det er for besværligt når man ind imellem ændre i databasen eller flytter databasen mellem servere.

Jeg vender tilbage senere når jeg har nogle logfiler der fortæller noget om hvilke sql-fejl og asp-fejl der har været undervejs.

På databaseserveren har jeg ca 200 linier der ligner denne:

"2005-03-01","09:15:19","80.208.60.10","-","10.2.2.115","80","GET","/LearningResource/Test/RunEksamenstest.asp","|120|80004005|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Transaction_(Process_ID_171)"_was_deadlocked_on_lock_resources_with_another_process_and_has_been_chosen_as_the_deadlock_victim._Rerun_the_transaction.","500","0","577","2860","Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+.NET+CLR+1.1.4322)"

Kan en manglende connection.close give anledning til en deadlock ?

På webserveren har jeg 2000 linier der ligner denne :

"2005-03-01","09:14:22","194.239.178.211","-","10.2.2.115","80","POST","/LearningResource/Test/RunEksamenstest.asp","|-|ASP_0147|500_Server_Error","500","226","683","4828","Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+98)"

Jeg formoder der er tale om den samme scriptfejl, men kan jeg på baggrund af ovenstående vide noget om hvad fejlen nærmere drejer sig om ?

arne_v>>
kan du nærmere beskrive hvad sp_who viser ?
Vil jeg kunne se der om der er en connection som ikke er blevet lukket ?

Jeg har fået en mistanke.

Tror i at det har væsentlig indflydelse at jeg i mine select-sætninger bruger låsningstype AdLockReadOnly og ikke AdLockOptimistic ?
Hvis AdLockReadOnly kan låse for andre brugeres inserts og updates i samme tabel er jeg nemlig ret sikker på at det vil have indflydelse på performance.
Ved I om "select tabel with unlock where ..." har smme effekt som AdLockOptimistic ? (eller er jeg helt hen i skoven) ?

sp_who viser hvilke connections der er

og ved at studere det mens applikationen kører må man kunne danne sig et indtryk af om
connections bliver lukket eller ej

AdLockReadOnly betyder at det er et readonly record set og formentlig betyder
det ingen locks på serveren overhovedet

Jeg kan se at mine linier i indlæg "04/03-2005 09:01:51" er blevet cuttet noget af

I den første linie står længere ude

deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Da jeg ikke erindre at have en eneste begin tran ... end trans i mit site og arne_v siger min AdLockReadOnly ikke låser noget forstår jeg ikke hvordan der kan opstå en deadlock ? -- noget må der da være låst ?

AdLockReadOnly er vel kun dine SELECT - hvad med dine INSERT/UPDATE - ingen
transaktioner ? ingen stored procdures ? ingen triggers ?

Det kan være jeg forstår begrebet transaktion forkert...
Selvfølgelig laver jeg insert og updates , men jeg har ingen stored procedures og triggers.
Jeg laver inserts og updates som i "03/03-2005 00:15:58". Men der angiver jeg ikke nogen  parameter a la AdLock....
inserts og updates kan vel ikke låse noget i sig selv.

Jeg har dog noget der er lidt voldsommere, som f.eks en select efterfulgt af en lykke hvor jeg for hver forekomst indsætter i en anden tabel. Dette efterfølges så af en delete af de indgange jeg først selectede.

stave kan jeg heller ikke, men uendelig lykke er måske også at foretrække fremfor uendelig løkke ...

jeg er vist løbet tør for gode ideer

sorry

Jeg er blevet enig med mig selv om at mit sites dårlig performance når der var flere hundrede samtidige brugere på som lavede mange insterts,updates og deletes samtidig ved brug af de samme tabeller skyldes

1)Mine algoritmer er langt fra optimerede og jeg laver flere connections end strengt nødvendig pr bruger
2)Jeg glemmer rent faktisk en del steder at lukke mine connections efter endt brug.
3)Jeg fandt denne interessante artikel omkring MS-SQL servers ikke optimale brug af låsning: http://www.4guysfromrolla.com/webtech/101100-1.shtml, hvori der foreslås at man ved at bruge "with (nolock)" i select-sætninger og "with (rowlock)" i update og deletes kan forhindre at ms-sql-serveren låser mere end højst nødvendigt. 

3) forklarer i hvert fald de 250 "was deadlocked on lock resources with anoher process and has been chosen as the deadlock victim. Rerun the transaction" fejl der blev logget
De ca 4000 "ASP_0147|500_Server_Error" fejl (som ikke er scriptstimeout) kan jeg ikke rigtig greje og jeg er ikke kommet nærmere ved at søge på nettet.

Så jeg forsøger at forbedre 1)-3) til næste gang.

Hvis I lægger et svar hver får i noget for venlig deltagelse

ok

håber det hjælper