Optimering av databasfrågor

[sundrik]

Jag har en sida som är går ner med jämna mellanrum. Har en känsla av att det har med databasen att göra. Eller mer exakt, mitt sätt att anropa dbn.

 

Som jag gör nu, så kör jag en include fil med db connection (connect.open) i början av varje sida.

Sen på själva sidan har jag massa olika execute.

I slutet av sidan har jag en include med connect.close

 

 

Jag har fått för mig att servern alltid läser hela sidan innan den skickas till användaren. Men tvivlar lite på detta.

T.ex. om jag i sidan har en Response.redirect, så slutar den läsa där och skickar vidare, och dbn stänger inte ordentligt?

[Cluster]

Ja, gör du en redirect innan du stänger databaskopplingen så "står den öppen".

Varför måste databaskopplingen vara öppen hela sidan, varför inte bara börja med att göra alla dina databasfrågor (och lägga värden i vanliga variabler) först och sedan göra presentationen?

Logik för att redirecta bör även det hanteras så tidigt som möjligt.

 

Men varför tror du att det är just oavslutatde databaskopplingar som gör att din sida går ned?

På vilket sätt går sidan ned, får du något felmeddelande?

[sundrik]

Det går ganska bra när man är ensam på sidan. Men kan ibland bli segt. Tex att det tar från flera sekunder uppåt 30sek att generera en sida.

 

När det blir flera på sidan samtidigt, så är det ganksa vanligt med sidgeneraringar på 10sek till 1min, och tillslut står den bara och laddar i evighet.

 

Sen efter 5-10min så går det att använda den sidan igen.

 

Först tänkte jag att det kunde vara att det blir för många sessions. Så jag gjorde om med cookies. Men felet kvarstod.

 

Nu har jag dock satt connect.close innan alla redirects jag har. Får se om det löser problemet.

 

 

 

Jag använder mycket DO UNTIL rs.EOF. Och vet inte hur jag skall lägga in sånt i strängar för att presentera senare.

 

Så nu måste jag köra db-frågor med pres, sen ännu db-fråga med pres. osv.

[Cluster]

Kör du på egen server eller webbhotell?

Vad är det för databas?

 

Du behöver ju inte databaskopplingen öppen för att kunna använda recordsets. Kolla t.ex. på sk. Disconnected Recordsets.

Du kan även direkt läsa in resultatet av databasfrågan i en array mha Getrows() som du kan använda efter det att databaskopplingen avslutats.

 

Se även till att alltid tömma recordset-objekten när du är klar med dem, typ

Set objRS = Nothing

 

För övrigt är Sessionsvariabler är en form av kortlivade cookies.

[sundrik]

Det är webhotell, surftown.

 

MySQL klientversion: 5.0.51a

 

 

i phpmyadmin hittade jag en flik med status. En del röda siffror där som jag inte vet riktigt vad det betyder. Förmodar att jag har riktigt kassa queries som drar ner databasen.

 

Lista på dom röda siffrorna:

Slow_queries	15 k	 Antalet frågor som har tagit mer än long_query_time sekunder.

Handler_read_rnd	835 M	 Antalet efterfrågningar att läsa en rad baserat på en fix position. Detta värde är högt om du ställer många frågor som kräver sortering av resultatet. Du har förmodligen många frågor som kräver att MySQL avsöker hela tabeller eller du har föreningar som inte använder nycklar på rätt sätt.

Handler_read_rnd_next	1 408 M	 Antalet efterfrågningar att läsa den följande raden i datafilen. Detta värde är högt om du gör många tabellavsökningar. I allmänhet antyder detta att dina tabeller inte är riktigt indexerade eller att dina frågor inte är skrivna för att dra nytta av de index du har.

Qcache_lowmem_prunes	57 M	 Antalet frågor som har tagits bort från cachen för att frigöra minne för cachning av nya frågor. Denna information kan hjälpa dig att ställa in storleken på frågecachen. Frågecachen använder strategin minst nyligen använd (LRU) för att bestämma vilka frågor som ska tas bort från cachen.

Created_tmp_disk_tables	2 649 k	 Antalet temporära tabeller på disk skapade automatiskt av servern under utförande av satser. Om värdet Created_tmp_disk_tables är stort vill du kanske öka värdet tmp_table_size för att åstadkomma att temporära tabeller lagras i minne istället för på disk.

Select_full_join	1 014 k	 Antalet föreningar som inte använder index. Om detta värde inte är 0, bör du noggrant kontrollera index för dina tabeller.

Select_range_check	12 k	 Antalet föreningar utan nycklar som kontrollerar nyckelanvändning efter varje rad. (Om detta värde inte är 0, bör du noggrant kontrollera index för dina tabeller.)

Sort_merge_passes	99 k	 Antalet sammanslagningar som sorteringsalgoritmen har behövt utföra. Om detta värde är stort bör du överväga att öka värdet i systemvariabeln sort_buffer_size.

Opened_tables	19 M	 Antalet tabeller som har öppnats. Om antalet öppnade tabeller är stort är förmodligen ditt tabellcache-värde för litet.

Table_locks_waited	40 k	 Antalet gånger som ett tabellås inte kunde förvärvas omedelbart och en väntan var nödvändig. Om detta värde är högt och du har prestandaproblem bör du först optimera dina frågor och antingen dela upp din tabell eller tabeller eller använda replikering.

 

Vet inte riktigt var man skall börja. Någon som vet en bra sida där man kan lära sig bättre optimering av queries kanske?

 

Kan tillägga att det är ingen högt trafikerad sida.

[Cluster]

Oerhört svårt att säga vad statussiffrorna betyder då jag själv inte jobbar med MySQL eller phpmyadmin.

 

Grunden för optimering är att se över datastrukturen/designen, sen gå igenom frågorna som körs och slutligen presentationen. Det är ett digert arbete och många "om och men"....

[gip]

Jag använder mycket DO UNTIL rs.EOF. Och vet inte hur jag skall lägga in sånt i strängar för att presentera senare.

Menar du att du gör en läsning från databasen, loopar igenom resultaten och gör en ny läsning för varje svar? I så fall kan du bygga om de frågorna så att du gör EN läsning där du får ut all intressant data.

 

Några slutsatser kan man dra från din logg. Det står ju tips efter varje värde. Det känns som att din databas inte är rätt konstruerad. Många av nyckeltalen är extremt stora, och det ska de inte behöva vara om din sida inte är särskilt trafikerad.

 

Utan att veta allt för mycket om din databas så verkar den sakna ordentliga nycklar och index. Alla tabeller ska ha ett nyckelfält och alla fält som används för att matcha ihop med andra fält och/eller för att söka i ska vara indexerade. Det betyder att om du tex har artikelnr som nyckel i artikeltabellen så ska artikelnr i alla andra tabeller också vara indexerade.

Detta är en rätt så enkel sak att åtgärda och skulle kunna vara något att börja med förutom att skriva om dina frågor enligt ovan.

[sundrik]

Nu har jag läst på lite vad ni menar med index oxh nycklar.

 

Alla tabeller jag har börjar med en kolumn som heter ID, denna är indexerad och nyckel.

 

Jag fattar nu att man kan även indexera andra kolumner i tabellen där man gör mycket sökningar för att det skall gå snabbare.

 

Den största tabellen jag har är på ca 3000rader. Innehåller mest int´s som jag gör en hel del sökningar på.

 

Jag skall även göra om en del med getrows, och se hur utfallet med det ger.

 

 

En sak jag inte fattar är hur man kan stänga databasen och fortfarande kör recordset?

[Cluster]

En sak jag inte fattar är hur man kan stänga databasen och fortfarande kör recordset?

Sök på "Disconnected Recordsets".

T.ex:

http://www.devguru.com/features/tutorials/DisconnectedRecordsets/tutDisconnRS.html

 

 

Se även "25+ ASP Tips to Improve Performance and Style"

http://msdn.microsoft.com/en-us/library/ms972335.aspx