---

Hey

Havde egentlig indtrykket af at Sored procedures altid var hurtigere, men
umiddelbart kan jeg ikke finde ud af at læse følgende, og efter at have kørt
det hele igennem en del gange må jeg indrømme at Cumulative client
processing time og Cumulative wait time on server replies skifter meget.
Nogen gange er det løsning et der er mindst andre gange løsning 2.

Uanset hvad bliver sql'en kaldt op til ca. 100 gange i en kørsel, og selvom
den er fuldt optimeret med clustered primary kay indexes på de to felter i
where klausulen, så ville det da være rart hvis den kunne køre endnu
hurtigere.

Mit spørgsmål er nu, hvilken er hurtigst. Løsning 1 eller løsning 2?

Følgende er skrevet ud ved at køre forespørgslerne i Query analyzeren:

LØSNING 1:
text
event class Duration CPU Reads Writes
set noexec off set parseonly off
SQL:StmtCompleted 0 0 0 0
select IS_SRVROLEMEMBER ('sysadmin')
SQL:StmtCompleted 0 0 0 0
SET STATISTICS PROFILE ON
SQL:StmtCompleted 0 0 0 0
select felt1 from table where felt2 = 720 and felt3 = 'tekst'
SQL:StmtCompleted 0 0 16 0
SET STATISTICS PROFILE OFF
SQL:StmtCompleted 0 0 0 0

Counter
Value Average
Application Profile Statistics
Timer resolution (milliseconds)
0 0
Number of INSERT, UPDATE, DELETE statements 0 0
Rows effected by INSERT, UPDATE, DELETE statements 0 0
Number of SELECT statements 2
1,23529
Rows effected by SELECT statements 3
1,85294
Number of user transactions
5 5,38235
Average fetch time
0 0
Cumulative fetch time
0 0
Number of fetches
0 0
Number of open statement handles 0
0
Max number of opened statement handles 0
0
Cumulative number of statement handles 0
0

Network Statistics
Number of server roundtrips
3 3
Number of TDS packets sent
3 3
Number of TDS packets received 7
6,97059
Number of bytes sent
264 239,529
Number of bytes received
3899 4012,65

Time Statistics
Cumulative client processing time
4 3,44118
Cumulative wait time on server replies 1,10317e+006
1,20318e+006


LØSNING 2:
text
event class Duration CPU Reads Writes
set noexec off set parseonly off
SQL:StmtCompleted 0 0 0 0
select IS_SRVROLEMEMBER ('sysadmin')
SQL:StmtCompleted 0 0 0 0
SET STATISTICS PROFILE ON
SQL:StmtCompleted 0 0 0 0
Select felt1 from table where felt2= @var2 and felt3= @var3
SP:StmtCompleted 0 0 19 0
exec sp_lang_tekst 720, 'tekst '
SQL:StmtCompleted 0 0 24 0
SET STATISTICS PROFILE OFF
SQL:StmtCompleted 0 0 0 0

Counter
Value Average
Application Profile Statistics
Timer resolution (milliseconds)
0 0
Number of INSERT, UPDATE, DELETE statements 0 0
Rows effected by INSERT, UPDATE, DELETE statements 0 0
Number of SELECT statements 0
1,2
Rows effected by SELECT statements 0
1,8
Number of user transactions
6 5,4
Average fetch time
0 0
Cumulative fetch time
0 0
Number of fetches
0 0
Number of open statement handles 0
0
Max number of opened statement handles 0
0
Cumulative number of statement handles 0
0

Network Statistics
Number of server roundtrips
3 3
Number of TDS packets sent 3
3
Number of TDS packets received 7
6,97143
Number of bytes sent
204 238,514
Number of bytes received
4263 4019,8

Time Statistics
Cumulative client processing time 4
3,45714
Cumulative wait time on server replies 432078
1,18115e+006

Umiddelbart er mit indtryk at løsning 1 er hurtigst, men jeg har heller ikke
megen forstand på at læse disse tal.


--


Jimmy

---

Jimmy wrote:

> Havde egentlig indtrykket af at Sored procedures altid var hurtigere,

Depends, kalder du den samme SP x antal gange er der en fordel fremfor alm
selects

> ...selvom den er fuldt optimeret med clustered primary kay indexes
> på de to felter i where klausulen, så ville det da være rart hvis den
> kunne køre endnu hurtigere.

Clustered primary key indexes er langt fra optimalt

Clustered sættes på statiske data, der ligger i klumper
Evt en foreign key kan være god at have som clustered index
Clustered indexes kan drille ved mange inserts/deletes

> Mit spørgsmål er nu, hvilken er hurtigst. Løsning 1 eller løsning 2?

Du kommer nærmere svaret når/hvis du arbejder med mere koplekse queries
SP kan også være performance killere hvis de ikke designes rigtigt og med
omtanke

Hvis der udskiftes hyppigt i databasen er SP's knap så gode
Alternativ skal man køre forskellige jobs for at opdateres
statistics/indexes mv udfra de "nye" data

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.dk> skrev i en meddelelse
news:3f6a14e1$0$32477$edfadb0f@dread16.news.tele.dk...
> Jimmy wrote:
>
> > Havde egentlig indtrykket af at Sored procedures altid var hurtigere,
>
> Depends, kalder du den samme SP x antal gange er der en fordel fremfor alm
> selects

Den bliver kaldt op til 100 gange i løbet af en sideindlæsning (Ja, jeg ved
godt at det nok godt kunne laves lidt smartere. ;))

> > ...selvom den er fuldt optimeret med clustered primary kay indexes
> > på de to felter i where klausulen, så ville det da være rart hvis den
> > kunne køre endnu hurtigere.
>
> Clustered primary key indexes er langt fra optimalt
>
> Clustered sættes på statiske data, der ligger i klumper
> Evt en foreign key kan være god at have som clustered index
> Clustered indexes kan drille ved mange inserts/deletes

Det er en statisk database. Der bliver kun ændret i den manuelt, altså ingen
insert, delete eller updates.

> > Mit spørgsmål er nu, hvilken er hurtigst. Løsning 1 eller løsning 2?
>
> Du kommer nærmere svaret når/hvis du arbejder med mere koplekse queries
> SP kan også være performance killere hvis de ikke designes rigtigt og med
> omtanke

Ja, jeg tænkte bare om ikke den simple sql ville køre hurtigere hvis den
blev kaldt som sp, da den virkelig bliver kaldt mange gange.

> Hvis der udskiftes hyppigt i databasen er SP's knap så gode
> Alternativ skal man køre forskellige jobs for at opdateres
> statistics/indexes mv udfra de "nye" data

Den er helt statisk tabellen. Men siger du så dermed at du ville vælge en sp
på denne forespørgsel?

Hvad kan man læse ud fra tallene i mit første brev?


Jimmy

---

"Jimmy" <pleasereplyingroup@hotmail.com> wrote
> "Peter Lykkegaard" <polonline@hotmail.dk> skrev

> > Hvis der udskiftes hyppigt i databasen er SP's knap så gode
> > Alternativ skal man køre forskellige jobs for at opdateres
> > statistics/indexes mv udfra de "nye" data
>
> Den er helt statisk tabellen. Men siger du så dermed at du ville vælge en
sp
> på denne forespørgsel?
>
Ja

> Hvad kan man læse ud fra tallene i mit første brev?
>
Ikke så meget, du har reelt 2 forespørgsler i eksemplet med din SP
Kør din ASP application samtidig med at du kører med profileren
Det skulle gerne give et fingerpeg

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> skrev i en meddelelse
news:hhzab.48$Z04.26@news.get2net.dk...
>
> "Jimmy" <pleasereplyingroup@hotmail.com> wrote
> > "Peter Lykkegaard" <polonline@hotmail.dk> skrev
>
> > Hvad kan man læse ud fra tallene i mit første brev?
> >
> Ikke så meget, du har reelt 2 forespørgsler i eksemplet med din SP
> Kør din ASP application samtidig med at du kører med profileren
> Det skulle gerne give et fingerpeg

Har prøvet, men jeg må ærligt indrømme at det ser meget ens ud, men skal jeg
være helt ærlig så taler det sådan alt i alt ikke til Stored procedures
fordel, med mindre man selvfølgelig ser på antal sendte bytes, der sparer
man 64 bytes hver gang forespørgslen kører.

Hm... I virkeligheden er det måske lige netop i dette tilfælde lige meget
hvad jeg gør.

> Overvej at trække dataene ud på een gang og sæt et filter på dit recordset
> efterfølgende

I know, men det var den lige den hurtige løsning jeg prøvede her, hehe...

Tak for svarene :)


Jimmy

---

"Jimmy" <pleasereplyingroup@hotmail.com> wrote in
> "Peter Lykkegaard" <polonline@hot.mail.com> skrev
> >
> > Kør din ASP application samtidig med at du kører med profileren
> > Det skulle gerne give et fingerpeg
>
> Har prøvet, men jeg må ærligt indrømme at det ser meget ens ud, men skal
jeg
> være helt ærlig så taler det sådan alt i alt ikke til Stored procedures
> fordel, med mindre man selvfølgelig ser på antal sendte bytes, der sparer
> man 64 bytes hver gang forespørgslen kører.
>
Hvordan kalder du din SP?
Kald den via Command objectet, så burde der ske lidt

Eller evt kør med en prepared select ligeledes via Command objectet

Men som tommerfingerregel må man sige at fordelen ved SP's stiger med
kompleksiteten
Der er jo ikke særligt meget der skal precompiles i dit tilfælde

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> skrev i en meddelelse
news:ynAab.74$2A4.73@news.get2net.dk...
>
> "Jimmy" <pleasereplyingroup@hotmail.com> wrote in
> > "Peter Lykkegaard" <polonline@hot.mail.com> skrev
> > >
> > > Kør din ASP application samtidig med at du kører med profileren
> > > Det skulle gerne give et fingerpeg
> >
> > Har prøvet, men jeg må ærligt indrømme at det ser meget ens ud, men skal
> jeg
> > være helt ærlig så taler det sådan alt i alt ikke til Stored procedures
> > fordel, med mindre man selvfølgelig ser på antal sendte bytes, der
sparer
> > man 64 bytes hver gang forespørgslen kører.
> >
> Hvordan kalder du din SP?
> Kald den via Command objectet, så burde der ske lidt
>
> Eller evt kør med en prepared select ligeledes via Command objectet
>
> Men som tommerfingerregel må man sige at fordelen ved SP's stiger med
> kompleksiteten
> Der er jo ikke særligt meget der skal precompiles i dit tilfælde

Næ, det har du selvfølgelig ret i. Jeg prøver lige med command objektet i
stedet.

Tak :)

---

"Jimmy" <pleasereplyingroup@hotmail.com> wrote in message
news:3f6a1104$0$97172$edfadb0f@dread12.news.tele.dk...

> Uanset hvad bliver sql'en kaldt op til ca. 100 gange i en kørsel

Overvej at trække dataene ud på een gang og sæt et filter på dit recordset
efterfølgende

mvh/Peter Lykkegaard

---

Jimmy wrote:
> Havde egentlig indtrykket af at Sored procedures altid var hurtigere, men

Det er korrekt for de fleste database typer. Det er kun enkelte
databasesystemer, såsom Microsoft SQL Server 2000, hvor det ikke er
tilfældet. Mig bekendt er det dog tilfældet i tidligere udgaver er MS SQL
Server.

Men ellers kan forskellen mellem stored procedure og ikke stored procedure
være så lille, at man bør overveje at smide SQL'erne ind i klienten
alligevel, for at bevare en veldesignet database. Hvis alt blev lavet som
stored procedures, ville man jo få tusindvis af dem i en typisk database
applikation.

> Følgende er skrevet ud ved at køre forespørgslerne i Query analyzeren:

Du skriver ikke, hvilket database system du bruger...

Hvis du f.eks. bruger Firebird, skal du bare sørge for at køre prepared
queries på klienten, og det er ligemeget, hvilken type SQL statements, du
fyrer af, og stort set ligemeget, om du kører alt i en transaktion eller i
flere.

Hvis du bruger MSSQL server, så er det en større videnskab at
hastighedsoptimere, da skidtet kan finde på at låse både records og
tabeller, og endda kan finde på noget så grotesk at lade transaktioner
udføre serielt hvis du laver de rette SQL statements.

Jeg kan ikke lige bruge dine tal til så meget - der er nemlig mange
parametre, der afgør, hvilken løsning, der er bedst. Den bedste løsning
kan:

1) Reducere performancenedsættelsen af andre, samtidige queries.
2) Levere første record hurtigst muligt (især vigtigt på websider)
3) Levere alle records hurtigst muligt

Og hvis man bruger et af de database systemer, der bruger log-filer, som
f.eks. Microsoft SQL Server, og hvis man kun har et harddisk system til sin
database, så skal man derudover også tage hensyn til, hvor meget der
skrives til log-filen.

Du kan selvflg. godt optimere din forespørgsel ved at måle op mod en bestemt
database server, med en bestemt datamængde og et bestemt netværk ved at
måle tiden for udførsel af din forespørgsel - men det er ikke særligt
sandsynligt, at din SQL statement vil opføre sig ligesådan andre steder.

Det er også derfor, at ibexpert (http://www.ibexpert.com/) ikke bekymrer sig
så meget om tider, når den analyserer en query, men i højere grad viser
hvordan din query er udført, hvilke indekser, der er blevet berørt, hvor
mange uindekserede opslag, der er foretaget etc. Så kan man selv danne sig
et overblik, om det virker efter hensigten.

Lars.

--
Freelance programmør

---

"Lars Dybdahl" <lars@dybdahl.dk> skrev i en meddelelse
news:3f6ad58e$1$128$edfadb0f@dread11.news.tele.dk...
> Jimmy wrote:

Der var lige lidt at tænke over kan jeg se. Ja, jeg bruger jo MS SQL Server,
så det... ;)

Tak for svaret :)