Optimering (viktigast stegvis)

Skulle nån vänlig själ kunna rangordna (så gott det går) en optimeringsplan åt mig.

Problemet:
Jag har byggt en asp, vb-script applikation i webbgränssnitt men sidan blir så tung att den timeoutar till slut.
Sidan innehåller bla. en loopad array med poster från databas(getrows)
Ett antal functions och subbar med recordsets (4-5 st) innuti arrayloopen.
Arrayloopen vet jag kan innehålla väldigt många poster.

Själv tror jag att det är i första hand datorn i sig som är för klen (p3, 450, 128, win2000 server, sql2000).

Jag behöver alltså göra nånting åt saken men frågan är då, var börjar jag:
Är det datorn som är för klen, vad i datorn i så fall, processor, minne?
Kan man göra justeringar i sqlservern, indexera, tilldela minne?
Finns det nått annat jag kan göra?

När det gäller asp-koden tror jag inte det finns så fruktansvärt mycket jag kan göra, inte heller tabellstrukturen i databasen.

Hoppas att jag beskrivit problemet tillräckligt.

Tacksam för svar /doggelito
(Måste tyvärr sticka nu men hoppas att jag har några svar imorgon bitti) :)

Jag kan ju tipsa om en sökning på en viss Lukaspojken...... ;)

Första steget är att ta reda på vad som går långsamt.

Du kan använda funktionen timer för att mäta.

p3, 450, 128, win2000 server, sql2000

Kan ju ligga där lite, det gör faktiskt mer än man tror, enligt mina upplevelser.

Jag frågar, även fast jag tror att du redan gjort det; har du option explicit längst upp? Det tillsammans med den obligatoriska dim:ningen gör sidan avsevärt mycket snabbare. Det finns ju givetvis mer prylar man kan göra också.

Jag skulle nog vilja se lite kod. (Helst i [kod]-taggar §e ;))

Oj, den datorn knäcker "min" utvecklingsserver...

Troligtvis är det kombinationer av loopar och databashanteringar.
Ett sätt att kolla, är att ta tid på olika ställen i koden, detta kan man göra på olika sätt. Ett annat är att på strategiska platser skriva info till en "debug" fil, som anger var ASP tolken befinner sig.

Jag ska gå igenom koden och tajma den på olika ställen.
Jag skriver väl här igen om jag inte hittar några optimeringpunkter.

Hur mycket påverkar hårdvaran i datorn asp-tolken och sqlservern?
Jag läste nånstans att sqlén jobbar till största delen i ramminnet, stämmer det?

Ett vanligt designfel ur prestandasynpunk är att man skapar för många objekt eller har många rundturer till databasen på en sida. Din rad "Ett antal functions och subbar med recordsets (4-5 st) innuti arrayloopen. " antyder att så är fallet.

Exempel på förödande kod avseende prestanda

rs.open ...
While

 sql= "SELECT * FROM tbl WHERE fldid=" & rs(0)
 rs2.open sql,cn,1,1
 - - -

Wend

Även om datorn är långsam borde det gå att köra som ensam användare. Att stoppa in lite mer RAM skulle dock underlätta din utvecklingsmiljö. Det finns massor av bra artiklar på MSDN om prestanda för IIS, ASP och VBScript. Till exempel:

• http://msdn.microsoft.com/library/en-us/dnasp/html/asptips.asp
• http://msdn.microsoft.com/library/en-us/dnserv/html/server03272000.asp
• http://msdn.microsoft.com/library/en-us/iisref60/htm/dwa_scl_aspscriptingopt.asp

Ett vanligt designfel ur prestandasynpunk är att man skapar för många objekt eller har många rundturer till databasen på en sida. Din rad "Ett antal functions och subbar med recordsets (4-5 st) innuti arrayloopen. " antyder att så är fallet.

Mm jag vet, så är också fallet, tyvärr!
Jag har funderat mycket på om jag kan kapa nånstans i koden, jag ser även över databasdesignen om jag kan justera tabellerna.
Inte helt enkelt dock, "många tabeller blir det"!
Kunskapen räcker heller inte riktigt till för att göra koden mer effektiv.

Men, men om ett år kommer man väl skratta åt denna stackars sida! :)

p3, 450, 128, win2000 server, sql2000

Borde inte vara fallet ... om inte en helt fel konfigurering har gjorts.

Många gånger så kan man hämta information i en exekvering, istället för att nestla recordsetet, med sk JOINs mellan olika tabeller.

För att vi ska kunna hjälpa till med förslag på vad som kan göras behöver vi nog få se koden ...

cya,
PatrikB

Jag kan nu meddela att mer ramminne gjorde susen.
Det har nu blivit bytt från 2x64 till 3x128. :bire och sidan öppnas
nu inom rimmlig tid (dock ska koden trimmas en del ändå).
/sen var det ingen p3 utan bara p2, (stackars burk)!