Väldigt slö sida

[MaZoR]

Jag driver en community för ett spel.

Jag uppfattar tyvärr sidan otroligt slö vid vissa tillfällen. Jag vet att servrarna är hur snabba som helst, och det är absolut inte det som är problemet. Det är heller inget fel på min uppkoppling (massor folk som klagat, och jag har provat på många olika ställen).

 

Jag fick tidigare ett tips om att jag måste stänga ALLA mina databaskopplingar. Det hade jag inte gjort tidigare. Jag la ner riktigt mycket tid på att stänga samtliga databaskopplingar. Det tog tid, men tyvärr blev det ingen märkbar skillnad.

 

Jag kom på en annan anledning till att sidan kan vara slö - adOpenStatic och adLockOptimistic.

Dessa två kommandon kör jag alltid efter att jag har öppnat en databaskoppling.

<%	file = Server.MapPath("gms.mdb")

Set Connect = Server.CreateObject("ADODB.Connection")
Connect.Open "driver={Microsoft Access Driver (*.mdb)};dbq="& file 

Set RecSet = Server.CreateObject("ADODB.Recordset")
Visa = "SELECT * FROM gms WHERE ID = " & Request.QueryString("ID") & " "
  RecSet.Open Visa, Connect, adOpenStatic, adLockOptimistic
%>

 

Så ser kopplingen ut. Jag har lärt mig att göra på det här sättet när jag började - men det är kanske fel? Är denna databas koppling slö?

Eller har det med adOpenStatic och adLockOptimistic att göra? Vad gör dom två kommandona överhuvudtaget?

 

Eller är det bara designen som är slö?

Jag har provat i många olika skins på sidan, (olika typer av designen) - har även testat de skins som bara är färg, alltså inga bilder.

Men det är ändå slött.

 

Adressen till sidan är www.starcraftgamers.com.

Kan någon hjälpa mig?

 

Tack på förhand.

 

[Jimmie Pettersson]

Kan det inte vara så att Accessdatabasen gör sitt till det hela. Det är kanske bättre att köra med MySQL?

 

Men jag tyckte personligen inte att sidan var seg. Snabbare än många andra sidor. Sitter på modem...

 

MVH Jimmie Pettersson

 

[Clas Ericson]

Så här bör du ställa in ditt recordset:

adOpenStatic - om du vill kunna hoppa framåt och bakåt bland posterna.

adOpenForwardOnly - om du endast ska lista posterna.

 

adLockOptimistic - om du ska uppdatera posterna du erhållit.

adLockReadOnly - om du inte ska ändra datat i posterna.

 

En annan sak som du kan göra för att snabba upp är också att använda recordset så lite som möjligt när du ska lägga till eller uppdatera data. Om du enbart vill lista poster så kan du använda metoden GetRows() för att erhålla posterna i en array. En array är snabbare att loopa igenom än ett recordset.

 

Andra saker som påverkar prestandan är hur dina sql-satser är formulerade. En tredje är hur du har indexerat databasen.

 

Mängden besökare är också ngt som kan slöa ner. Access är ju inte alltför bra på många samtidiga användare. Detta beror dock mycket på vad som görs med databasen.

 

Detta ämne har diskuterats ganska mycket på Eforum under de senaste åren. Sök lite i ASP & VBScript samt Databaser & SQL så hittar du fler tips och råd.

 

//Clas

 

[MaZoR]

Okay.

Tack för svaren.

 

Men dessa 4 kommandon du talar om, sölar det ner om jag har någon med som inte behövs?

 

[Clas Ericson]

Men dessa 4 kommandon du talar om, sölar det ner om jag har någon med som inte behövs?

Ja, markören adOpenStatic är lite långsammare än adOpenForwardOnly. Hur mycket vågar jag inte yttra mig om, men det finns iaf en liten skillnad i prestanda. Detta pga adOpenStatic kräver lite mer "overhead".

 

 

//Clas

 

[MaZoR]

Med andra ord, jag kan alltså tjäna extra snabbhet genom att ta bort det kommandot där jag inte använder det?

 

[Clas Ericson]

Genom att använda rätt markörtyp och rätt låsning av posterna optimerar du ditt recordset, ja. Läs gärna mer om detta på MSDN, http://msdn.microsoft.com Du hittar informationen under avsnittet om ADO.

 

 

//Clas

 

[foo]

Hej!

 

Snygg och avancerad site! Grymt impad

 

Dock hade du en felstavning längst ned i footern... version heter det

 

Hur som, tänkte bara komplettera Claes inlägg. Rent generellt skall man aldrig använda ServerSide cursors i en webblösning som är som din. Använd istället ClientSide cursor samt välj mellan ForwardOnly alternativt Static cursor. Om du har avancerad logik kan du av skalbarhetsskäl, disconnecta recordseten och stänga connection mellan bearbetningarna/databasanropen.

 

Enklaste sättet i ASP är att skapa ett recordset implicit genom att anropa execute metoden på Connection objectet:

 

Läsa

set arsData = oConn.execute(sSQL)

 

Uppdatera

call oConn.execute(sSQL,, adNoRecordsAffected)

Den sista parametern ser till att det inte skapas något resultatset.

 

Man kan även återanvända recordset objekt. Om du först hämtar nyheter i ett recordset, kan du hämta nytt data och i samma objekt (naturligtvis försvinner det ursprungliga datat). Detta kan vara att föredra om du gör många slagningar samt för att undvika många object instansieringar som är dyrbara.

 

En kommentar till att hämta ut poster som arrayer. Det är oftast en försumbar prestandaskillnad mellan dessa två alternativ. När man utvecklar är det bäst att alltid vara konsekvent i sina lösningar. Annars kan koden lätt bli råddig. Om man nu behöver göra prestandaförbättringar gör man det efteråt istället. Oftast kan man större prestandavinster på andra ställen i systemet.

 

Tipset om sql satserna skall du verkligen ta på allvar. Dåligt skriven sql kod kan slöa upp rejält, oftast räknat i sekunder.

 

Sedan bör det påpekas att ASP inte är snabbt. Dessutom använder man många "lata" lösningar som är lätta att använda men som kan slöa upp ditt system. Många bäckar små...

Exempelvis ärServer.MapPath funktionen långsam. Varför körs den vid varje ASP sida, det räcker ju om du kör den en gång och lägger in resultatet i en Application variabel istället.

 

Sedan kan du också kika lite på en cachningsfunktion för exempelvis nyheter. Jag såg att samma nyhetslista återfinns på de flesta sidorna. Nyheter ändras inte så ofta och då kan de med fördel cachas antingen som en färdig html kodsnutt eller om du hellre vill cacha recordsetet.

Detsamma gäller annan information som du har i den högra listen på förstasidan. Det är ju information som bara behöver uppdateras när något verkligen har uppdaterats.

 

Du kan ju klura lite på varför förstasidan är lika långsam som din nyhetssida?

 

Det var många synpunkter men kom ihåg att du oftast bara behöver åtgärda några punkter för att få bra prestanda. Att optimera för mycket brukar oftast inverka negativt på förvaltningsbarheten/vidareutvecklingen senare.

 

/foo

 

[supreme]

Jag tror ju iofsig att det är recset som ställer till det, det är ju betydligt snabbare att hämta allt på en gång och sedan stänga skiten, vet inte vad detta kallas, men det kör iaf jag.

 

Och om det är en acessdatabas och det är många besökare så kan det också vara en flaskhals.

 

Är du intresserad av vad jag har att säga skicka ett mail till edvard@itkonsulterna.nu så kan jag skicka lite kod eller liknande till dig.

 

 

mvh edvard

 

[Magnus Gladh]

Rent generellt skall man aldrig använda ServerSide cursors i en webblösning som är som din.

 

Nu blev jag nyfiken, det jag vet så är klientcursorn nästan dubbelt så långsam som servercusrsorn.

 

Men om du menar att man skall hämta all data på 1 gång och lägga i ett stor recordset, istället för att koppla upp sig en massa gånger, så kanske jag kan hålla med dig. Men det beror ju också på lite vad man hämtar, för så länge man använder connection pooling så kostar det inte så mycket att koppla upp sig mot databasen, och speciellt inte om databasen ligger på samma server (hemsk tanke).

 

Det finns ett annat kommando som nästan ingen använder och det är .cachesize där kan du ställa in hur många records som skall hämtas åt gången från databasen. Default är 1 men det är ju rätt dumt att hämta 1 record åtgången om man har 1000 record som skall visas, bättre att hämta typ 100 åt gången då istället.

 

Generellt skulle jag säga att du alltid skall använda adOpenForwardOnly och adLockReadOnly tilsammans med en serverside cursor. Speciellt om du använder dig av MS SQL Server eftersom man då använder SQL NativeCursor som är MYCKET snabbare.

 

Framför allt hade jag byt ut din drivrutin mot en OLEDB som är snabbare och pålitligare (http://www.connectionstring.com) men även tittat på "Prepared Questions", alltså en enkel variant av "kompilerade frågor i ADO" vilket även snabbare upp om du har många likadana SQL frågor.

 

GetRows() har jag blandad erfarenheter om, jag gjorde ett eget test som visade att GetRows() inte alls var så mycket bättre än .movenext (http://www.gladh.nu/asphelp/svar22.html)

 

Generellt så kan jag säga att rättskrivna SQL satser snabbare upp mycket, samt att man gör det mesta i sin SQL kod och inte i sin ASP-kod. Jag har sett skräckexempel på inloggningar där man tar ut ALLA användare med en:

SELECT * FROM [user]

och sedan loopar igenom hela recordset och jämför varje post mot de värde man har. Istället för att skriva:

SELECT Count(1) FROM [user] WHERE [usernamne] = 'Magnus'

 

Är det så att du har egentillgång till servern, så kanske en kompilerad DLL kan hjälpa till att öka prestandan, eller varför inte byta databas till MySQL som är snabb..

 

- Magnus

-----------------------------------------------------

ju mer jag lär mig ju mer inser jag så lite jag kan

 

[MaZoR]

Testar att svara. Funkar inte, det blir 404.

 

[foo]

hejohå 10 tecken

 

[foo]

Hej Magnus!

 

Jag anser att serverside cursors skall undvikas i webblösningen pga slöseriet med databas resurser (connections). Varför låsa upp en connection/databas bara för att hämta data?

 

I webbsammanhang hämtar man oftast små mängder data. Att då använda sig av en clientside cursor skulle frigöra en connection betydligt snabbare än att ha ett recordset knutet till en activ connection samtidigt som man loopar igenom det. För varje movenext slår ADO mot databasen vilket inte är bra. Det är endast om man vill hämta stora mängder data som det är försvarbart att använda en serverside cursor.

 

Argumentet att hämta alla poster samtidigt skulle vara långsamt håller jag inte med om eftersom Access är en client-only databas. Dessutom bör skalbarheten prioriteras högst när det handlar om Access.

 

...

 

[foo]

...

 

 

Att en clientcursor är långsammare än en server dito är inte korrekt, tvärtom. Dock tar det längre tid att hämta recordsetet eftersom ALL data måste hämtas samt index nycklas upp. Det är detta som gör att det kan ta längre tid, dock när man väl har datat så är en clientcursor mycket snabbare.

 

Vad gäller .cachesize så är det en clientside cache. Dvs datat hämtas in och cachas i recordsetet och om du då har en dynamic client-cursor kan ditt dataset hamna ur sync om en post tas bort i din databas (förutsatt att du håller dig inom cachen, rör du dig utanför synkas recordsetet igen). Det är just därför default värdet är satt till 1.

 

/foo

 

 

[MaZoR]

Ööh. Foo jag försöker svara till dig, har ett meddelande. Men såfort jag klistrar in det så blir det 404 error, och jag kommer inte in på sidan på en timme eller två. Har du email man kan skicka till?

 

[foo]

Hej!

 

tjo tror att det är något fel som gör att man inte kan posta större mängder text. Jag delade upp min post och sedär, då gick det minsann

 

Om du postar och får fel från IDGs Eforum måste du stänga ned din browser och öppna en ny instans, då slipper du vänta i timmar.

 

/foo

 

[inlägget ändrat 2003-01-11 11:12:55 av foo]

[Magnus Gladh]

Intressant, det låter vettigt det du säger, får granska boken en gång till och se vad som står där, den är rätt gammal (för ADO 2.1) men där var bra testar om prestandan...

 

Skall göra ett eget litet test också, är inte riktigt villig att ge upp än

 

- Magnus

-----------------------------------------------------

ju mer jag lär mig ju mer inser jag så lite jag kan

 

[MaZoR]

Tack för berömmet på sidan. Jag har rättat stavfelet =)

 

 

Jag måste också tacka för att ni har ansträngt er och skrivit mycket till mig - men tyvärr i onödan.

Men tanke på att jag har lärt mig genom att kolla på min kompis kod (han som gjorde grundesignen och programmeringen åt mig) har jag inga grundläggande kunskaper själv.

Tyvärr har jag därför väldigt svårt att följa med i era förslag och alla termer. Jag har mina egna termer och funktioner som funkar för mig, efter att jag testat mig fram.

 

Skriv vänligen om lite så att jag förstår =)

 

 

[MaZoR]

"Du kan ju klura lite på varför förstasidan är lika långsam som din nyhetssida?"

 

Förstasidan är lika långsam för den sparas inte i cacheminnet.

Problemet med startsidan var (som jag tog upp i ett tidigare inlägg för några dagar sen som heter "Response.buffer") att skinsystemet (utseendet på siten) sparades i cacheminnet och när man bytte skin så sparades inte förstasidan med skinnet i cachen.

Med andra ord: det gamla skinnet var kvar när man kom in på sidan och när man klickade sig vidare kom det nya skinnet istället upp.

 

Det där att man kan sätta cache på nyheterna: Det uppdateras visst. Ofta. Minst 3-4 gånger per dag.

Är det värt att sätta cache då?

 

 

[MaZoR]

Du som verkar så duktig, foo, får gärna hjälpa mig lite allmänt med programmeringen så siten om du har lust, så trycker jag in dig i crew. =)

 

 

 

"Tipset om sql satserna skall du verkligen ta på allvar. Dåligt skriven sql kod kan slöa upp rejält, oftast räknat i sekunder."

 

Tyvärr vet jag inte vilket tips du syftar på.

 

 

Tack för hjälpen. Men skriv gärna om min ursprunliga databaskoppling så att den stämmer med det nya ni talar om. Är väldigt tacksam.

 

 

Nu fick jag med allt =)

 

[foo]

Hej!

 

Tror det är bättre om du tar hjälp av hela forumet här istället för bara en person. Det finns många här som kan bidra med tips och alla har nytta av att kika på andras lösningar.

Skicka upp koden för din förstasida så kan vi hjälpa dig.

 

/foo