[SQL / ASP] Hoe een snellere Server Connectie?

[Verwijderd]

Best mensen, ik ben in middels de trotse bezitter van een MS SQL database (yeh!). Er zijn al een aantal pagina's omgezet naar de MS SQL openings string. Nu viel mij op dat als ik "openpaginaSQL.asp" open, dat de parse time ong. 5 sec. is. Ga ik de pagina refreshen dan is de parsetime in een keer 0,0469 sec.

5 seconden vind ik te lang. Helemaal voor een snelle SQL database. Wat zijn de punten waar ik de connectie sneller kan maken?

Dit is mijn code van "openpaginaSQL.asp"

ASP:

Connection = "Provider=sqloledb;" & _ 
             "Data Source=xx.xx.xx.xx;" & _
             "Initial Catalog=xxxxxxx;" & _
             "User Id=xxxxxxxxx;" & _
             "Password=xxxxxxxxxx"

Set Database = Server.CreateObject("ADODB.Recordset")

SQL = "SELECT TOP 2 tblNaam.date AS naam_datum," & _ 
      " tblNaam.activatie AS updatess, tblNaam.text AS naam_text " & _
      "FROM tblNaam ORDER by tblNaam.ID DESC;"

Database.CursorType = 1
Database.LockType = 3
Database.Open SQL, Connection


   if Database("updatess") > now() then
       Database.movenext()
   else
       database.movefirst()
   end if


response.write(database("naam_text"))


database.Close()

De tabel "tblNaam" bevat maar 100 records...

Wie o wie heeft tips voor mij
-alvast bedankt!

[ Voor 19% gewijzigd door Verwijderd op 21-06-2003 12:18 ]

[gorgi_19]

Zet, voor de zuiverheid, ook eens een tellertje tussen regel 6 en 8, 12 en 16, 16 en 24

[ Voor 9% gewijzigd door gorgi_19 op 21-06-2003 12:24 ]

[Verwijderd]

gorgi_19 schreef op 21 June 2003 @ 12:21:
Zet, voor de zuiverheid, ook eens een tellertje tussen regel 6 en 8, 12 en 16, 16 en 24

Pffffffffoe oké

[whoami]

Maak gebruik van stored procedures ipv je query zo in je code te concateneren.

Zie ook hier:
[rml][ ASP.NET] Webdev tips[/rml]

[_Thanatos_]

Je kan een aantal dingen doen, zowel makkelijke als moeilijke. Maar eerst de verklaring waarom het eerst 5 seconden duurt en de tweede keer <1 seconde: ASP wordt gecompileerd. Weliswaar niet naar x86 code, maar het wordt echt gecompileerd naar iets dat sneller uitgevoerd kan worden.

Ok, wat je kan doen om je databse-verbinding sneller te maken:
• Voor iedere pagina nooit meer dan één connection-object hebben klaarstaan en daarop je queries uitvoeren. Dit kun je doen met een include aan het begin, waar je de verbinding in aanmaakt, en een include aan het einde, waar je de verbinding sluit en vrijgeeft.
• Je kan persistent connections gebruiken. Hiermee blijft een database-verbinding openstaan totdat de sessie of applicatie beëindigd wordt (weet niet persies welke van de twee). Hoe dit persies werkt weet ik niet, maar Google wel.
• Tot slot als je ASP.NET gaat gebruiken, kun je gebruik maken van een aantal slimme ingebouwde cacheing-machanismen, die het aantal requests naar de database kunnen minimaliseren.

Maargoed, toch denk ik niet dat je database de bottleneck is. Het is immers ASP dat uitgevoerd moet worden en dat is geen x86 code.

[ Voor 1% gewijzigd door _Thanatos_ op 21-06-2003 13:50 . Reden: typo's ]

[gorgi_19]

_Thanatos_ schreef op 21 June 2003 @ 13:49:
Je kan een aantal dingen doen, zowel makkelijke als moeilijke. Maar eerst de verklaring waarom het eerst 5 seconden duurt en de tweede keer <1 seconde: ASP wordt gecompileerd. Weliswaar niet naar x86 code, maar het wordt echt gecompileerd naar iets dat sneller uitgevoerd kan worden.

Je bent nu in de war met asp.net. Daar duurt het laden van een pagina de eerste keer langer.

ASP interpreteert iedere keer de pagina, dus dit zou in principe geen verschil mogen geven.

Een databaseconnectie open laten staan, vind ik iig geen goed advies. Aangezien er ook in ASP Connection Pooling zit, kan deze de boel veel beter afhandelen dan je zelf doet. Dus zo snel mogelijk een connectie sluiten, nadat je hem gebruikt hebt en op deze manier de connectie weer vrijgeven.

[ Voor 21% gewijzigd door gorgi_19 op 21-06-2003 13:55 ]

[Verwijderd]

Ik vroeg me ook nog af, ik heb die Access database ge-upsized naar SQL. Mag de kolom "upsize_ts" er uit?! bevoerderd dat de snelheid niet al veel meer?

[Verwijderd]

Ik bedenk net een nieuwe manier om dit te doen in asp zonder tijd te verliezen bij het halen van data uit je db

Als je nu dit laat uitvoeren in je global.asa bij een nieuwe sessie, dan wordt het proces op de achtergrond gehouden!
Je maajt dan een array die je opslaat in een applicatievariabele en die vraag je op via je asp pagina!
Misschien niet de properste methode maar als je stored procedures gebruikt en propere code dan denk ik dat je het toch al vrij mooi hebt gedaan

[robjanssen]

Probeer deze methode eens:

ASP:

ConnectionString = "Provider=SQLOLEDB.1;" & _ 
             "Data Source=xx.xx.xx.xx;" & _
             "Initial Catalog=xxxxxxx;" & _
             "User Id=xxxxxxxxx;" & _
             "Password=xxxxxxxxxx"

Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open ConnectionString

strSQL = "SELECT TOP 2 tblNaam.date AS naam_datum," & _ 
      " tblNaam.activatie AS updatess, tblNaam.text AS naam_text " & _
      "FROM tblNaam ORDER by tblNaam.ID DESC;"
Set rsNaam = Server.CreateObject("ADODB.Recordset")
rsNaam.Open strSQL, Conn, 0, 1

If Not rsNaam.EOF Then
  If rsNaam.Fields("updatess") > Now() Then
    rsNaam.MoveNext()
  Else
    rsNaam.MoveFirst()
  End if
End If

Response.Write rsNaam.Fields("naam_text")

rsNaam.Close
Set rsNaam  = Nothing

Conn.Close
Set Conn = Nothing

[gorgi_19]

Verwijderd schreef op 21 June 2003 @ 14:25:
Ik bedenk net een nieuwe manier om dit te doen in asp zonder tijd te verliezen bij het halen van data uit je db

Als je nu dit laat uitvoeren in je global.asa bij een nieuwe sessie, dan wordt het proces op de achtergrond gehouden!
Je maajt dan een array die je opslaat in een applicatievariabele en die vraag je op via je asp pagina!

Erhm.. Wil je een sessie hier mee belasten? En applicatievariabelen heb je hierbij niet nodig (staan iig niet in relatie met een sessie, in dit geval)

Sessie variabelen moet je gebruiken voor veelgebruikte, user gebonden data. Ik betwijfel er hier sprake van is.

Verder geef je global.asa aan; dit zou qua snelheid niet uit mogen maken. Global.asa wordt gewoon in dezelfde context uitgevoerd; er wordt geen thread parallel aangemaakt hiervoor.

[Verwijderd]

gorgi_19 schreef op 21 June 2003 @ 15:25:
[...]

Erhm.. Wil je een sessie hier mee belasten? En applicatievariabelen heb je hierbij niet nodig (staan iig niet in relatie met een sessie, in dit geval)

Sessie variabelen moet je gebruiken voor veelgebruikte, user gebonden data. Ik betwijfel er hier sprake van is.

Verder geef je global.asa aan; dit zou qua snelheid niet uit mogen maken. Global.asa wordt gewoon in dezelfde context uitgevoerd; er wordt geen thread parallel aangemaakt hiervoor.

Ik heb het al opgelost er was een probleempje op de SQL Server zelf waardoor die langzaam de requests doorvoerden. en wouw!!! wat is MS SQL db een super vordering ipv dat Access

Ff snel: Hoe voer ik makkelijk zo'n stored procedure in / uit? (dat neem ik terug )

Het werkt woei! Ik heb de SQL tag in een stored procedure gezet. en idd, de parse time is nu niet 0,0469 sec maar 0,0251 sec (oja, dan wordt er ook nog een xml file geladen van een andere server op de wereld (ASP powerrrrrr)

Bedankt voor de tips en het meedenken!

[ Voor 21% gewijzigd door Verwijderd op 21-06-2003 16:25 ]

[Verwijderd]

Oja, btw, zónder het inladen van die XML file wisseld de parse time tussen de 0,0156 én 0,000

[_Thanatos_]

Je bent nu in de war met asp.net. Daar duurt het laden van een pagina de eerste keer langer.

Nee hoor, classic ASP wordt ook gecompileerd. En bij mij duurt het de eerste keer ook langer, ook al doe ik niets met een database. Hoe anders kun je "VBscript compilation errors" krijgen?

[Verwijderd]

_Thanatos_ schreef op 21 June 2003 @ 21:52:
[...]

Nee hoor, classic ASP wordt ook gecompileerd. En bij mij duurt het de eerste keer ook langer, ook al doe ik niets met een database. Hoe anders kun je "VBscript compilation errors" krijgen?

-> Gewoon omdat ze gecompileerd worden on-the-fly elke keer dat je een pagina aanvraagt?
Ik had nog nooit gehoord van asp-pagina's waarvan de gecompileerde versie automatisch gecached wordt.

Volgens mij heb je half gelijk:
4guys from rolla
Scripting languages have two disadvantages over compilable languages (like Visual C++ or VisualBasic). First is performance; each time an ASP page is visited, these scripts are interpretted by the appropriate scripting engine and a version of their execution plan was cached to increase performance. This cache, though, is an in-memory cache, so at any time only a small number of "interpretted" ASP pages can actually be cached.

[ Voor 35% gewijzigd door Verwijderd op 21-06-2003 23:47 ]

[whoami]

_Thanatos_ schreef op 21 juni 2003 @ 21:52:
[...]

Nee hoor, classic ASP wordt ook gecompileerd. En bij mij duurt het de eerste keer ook langer, ook al doe ik niets met een database. Hoe anders kun je "VBscript compilation errors" krijgen?

Classic ASP is interpreted en niet compiled.
Dat ze gecached worden heeft ook niets te maken met compilatie.

[ Voor 9% gewijzigd door whoami op 22-06-2003 10:08 ]