[ASP] veel queries trager dan bij PHP?

[Vigory]

Ik heb een paar webapplicaties met (zeer kleine) database met vertalingen. Op 1 pagina wordt elk stuk tekst uit de database gehaald, wat een groot aantal queries betekent. (bijv. 60 op 1 pagina). PHP met MySQL heeft daar geen enkel probleem mee, de pagina's laden supersnel in.

Op een server met ASP en MSSQL gaat het veeeel trager, het is steeds even wachten voordat de pagina op je scherm staat.

In beide gevallen staan de SQL server en de webserver op dezelfde machine. Is ASP/SQL nu echt zo bagger voor veel queries of zit er iets niet goed in de configuratie?

[whoami]

SQL Server is een snelle databank, maar als jij geen indexen of geen goeie indexen legt, dan kunnen je queries idd wel trager zijn.

Als een webpagina traag is, dan zal het aan de programmeur en aan de opzet van die pagina liggen, of aan het data-model en de al of niet aanwezigheid van indexen.
De bottleneck zal heus ASP of SQL Server niet zijn.

[ Voor 46% gewijzigd door whoami op 11-06-2004 12:09 ]

[NMe]

ASP zou juist wel de bottleneck kunnen zijn. Als je bijvoorbeeld je pagina eerst genereert en in één string opslaat, en dan in één keer afdrukt dan gaat dat in PHP perfect. ASP heeft echter veel meer moeite met bewerkingen op (langere) strings, en is daar dus ook wat trager mee. Je zal even moeten kijken in welke mate iets dergelijks op jou van toepassing is.

[_Thanatos_]

De queries verzamelen in een string en daarna in een keer naar de server sturen, dat maakt ook erg veel verschil. Mits je die mogelijkheid hebt natuurlijk.

En natuurlijk 1 verbinding maken en daarover je queries sturen, dus niet voor iedere query een verbinding maken.

Daarnaast het is bij PHP/MySQL vaak zo dat ze beide op dezelfde server staan, terwijl dat bij ASP/MSSQL weer vaak niet zo is.

[4of9]

kan aan zoveel dingen liggen, zonder code voorbeelden denk ik niet dat men hier kan zeggen waar het aan ligt...

[Verwijderd]

Wat wel zeker is, is dat ASP bij LANGE(!) strings erg traag wordt. Dat kan het probleem zijn, je string moet wel echt erg, erg lang zijn.
De MSSQL zal het probleem niet zijn, zowel dan moet je echt een flink brakke database in elkaar hebben gedraaid of stomzinnege SQL query's uitvoeren tegen dat ding, daar gaan we maar even niet van uit.

[4of9]

als je 60 query's op 1 pagina zet denk ik dat je je code eens goed na moet kijken en het gebruik van stored procedures moet overwegen.

Maar wat code zou nog steeds fijn zijn om te kunnen beoordelen of het aan de gebruiker zelf licht of aan iets anders...

[gorgi_19]

* gorgi_19 gokt dat cachen icm een Dictionary-object oid in een Application variabele meer en betere effecten heeft dan een SQL statement te proberen optimaliseren in dit geval.

[ Voor 5% gewijzigd door gorgi_19 op 11-06-2004 16:53 ]

[Vigory]

De code is als volgt:

code:

<%
    Dim DataConn

    Set DataConn = Server.CreateObject("ADODB.Connection")
    DSNtemp = "DSN=" & DSN & ";UID=" & UserName & ";PWD=" & Password
    DataConn.Open DSNtemp
%>

<%=vertaal("inleiding") %>

<%=vertaal("item1") %>

<%=vertaal("item2") %>

<%=vertaal("item3") %>

<%=vertaal("footer") %>


%>
  DataConn.close
  set DataConn=nothing



Function vertaal(tekst_id)

    Set rs = DataConn.execute("SELECT en FROM vertaling WHERE tekst_id = '" & tekst_id & "'")
    If rs.eof Then
        vertaal = ""
    Else
        vertaal = rs(0)
    End If
    rs.close
    set rs = nothing

End Function
%>

De code is wat ingekort, maar het gaat er om dat de vertaal functie heel vaak wordt aangeroepen. Dit maakt de pagina erg traag, terwijl een vergelijkbare pagina met mysql/php supersnel inlaadt. Iemand enig idee waar het verschil in zit?

[whoami]

Bekijk eens het execution plan van die query in Query Analyzer.

Je bent zeker dat je een index hebt op tekst_id ?

[gorgi_19]

De code is wat ingekort, maar het gaat er om dat de vertaal functie heel vaak wordt aangeroepen. Dit maakt de pagina erg traag, terwijl een vergelijkbare pagina met mysql/php supersnel inlaadt. Iemand enig idee waar het verschil in zit?

Maar wat is er mis met de cache-optie van een dictionary object?

[ Voor 7% gewijzigd door gorgi_19 op 17-06-2004 13:34 ]

[Vigory]

whoami schreef op 17 juni 2004 @ 12:15:
Bekijk eens het execution plan van die query in Query Analyzer.

Je bent zeker dat je een index hebt op tekst_id ?

Ja, er zit een index op. Volgens de query analyzer kost de index seek het meeste. Deze heeft een estimated cost van 6 (600%).

[ Voor 3% gewijzigd door Vigory op 17-06-2004 13:28 ]

[4of9]

Je zou zoiezo eens een dsn loze connection string kunnen gebruiken (server moet dan in de registry gaan zoeken)

En als text_id een int() veld is, kun je het beste je index op een ander veld leggen.

[P_de_B]

Hoeveel vertalingen heb je grofweg? Volgens mij kun je ze beter _allemaal_ in een array plaatsen, dan voor elk woord opnieuw naar de db te gaan.

[whoami]

4of9 schreef op 17 juni 2004 @ 13:30:


En als text_id een int() veld is, kun je het beste je index op een ander veld leggen.

Waarom? Waarom zou je een index op een ander veld leggen, als je toch niet op dat ander veld selecteert?
Een tabel kan trouwens meerdere indexen hebben.

[4of9]

het schijnt zo te zijn (van horen zeggen) dat een index op een niet nummerieke waarde sneller is (in mssql)

[P_de_B]

4of9 schreef op 17 juni 2004 @ 13:39:
het schijnt zo te zijn (van horen zeggen) dat een index op een niet nummerieke waarde sneller is (in mssql)

Maar je legt toch de index op het veld waarop je zoek

[Verwijderd]

set rs = nothing hoeft toch niet elke keer?

[Vigory]

Het zijn zo'n 150 vertalingen. Misschien is het inderdaad een om alles via een dictionary of array in een application variabele te zetten en het op die manier te cachen. Dat ga ik maar eens proberen, bedankt voor tip!

tekst_id is overigens al een varchar (de naam idd verwarrend )

Ik dacht dat rs = nothing wel altijd moet omdat het object anders in het geheugen blijft hangen? Interned Services heeft er een keer over geklaagd dat we dat niet deden, ik heb er nooit echt goede bronnen over gevonden.

[4of9]

het is beter om het wel te doen.

[whoami]

4of9 schreef op 17 juni 2004 @ 13:39:
het schijnt zo te zijn (van horen zeggen) dat een index op een niet nummerieke waarde sneller is (in mssql)

Da's quatsch.
Het zal zelfs juist omgekeerd zijn.

Trouwens, wat heb je aan een index op een bepaald veld, als je niet filtert op dat veld?

[Verwijderd]

Vigory schreef op 17 juni 2004 @ 13:54:Ik dacht dat rs = nothing wel altijd moet omdat het object anders in het geheugen blijft hangen? Interned Services heeft er een keer over geklaagd dat we dat niet deden, ik heb er nooit echt goede bronnen over gevonden.

Volgens mij alleen als je hem echt niet meer gebruikt, op het laatst dus.

[Verwijderd]

Performanceverlies wordt sowieso veroorzaakt door een niet-native verbinding.

ASP -> ADODB -> db-library -> database
PHP -> (native) db library -> database

Daarnaast...
60 queries op één pagina?

Kun je niet een aantal queries combineren door één grote query te maken en het resultaat dan serieel doorlopen?

[ Voor 27% gewijzigd door Verwijderd op 17-06-2004 22:37 ]