/ Forside / Teknologi / Udvikling / ASP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
ASP
#NavnPoint
smorch 9259
Harlekin 1866
molokyle 1040
Steffanst.. 758
gandalf 657
smilly 564
gibson 560
cumano 530
MouseKeep.. 480
10  Random 410
Sløve opslag mod SQL
Fra : Martin Rise Christen~


Dato : 22-02-01 18:31

Jeg har netop oversat en side fra at kører op mod en MS Access database og
ændret til at kører op med en sql server - hvilket også virker - MEN den er
blevet ikke bare langsom men ekstremt langsom.

Jeg bruger ikke named pipes men IP som provider.

SQL serveren kører på en seperat/anden maskine.

Når jeg kører på min egen pws, med odbc kilde kører det perfekt men på
serveren går det simpelthen i stå.

Er der nogle bud?

Mvh,

Martin Rise Christensen



 
 
Jakob Andersen (22-02-2001)
Kommentar
Fra : Jakob Andersen


Dato : 22-02-01 19:00

"Martin Rise Christensen" <martin@rise.dk> wrote
> Jeg har netop oversat en side fra at kører op mod en MS Access database og
> ændret til at kører op med en sql server - hvilket også virker - MEN den
er
> blevet ikke bare langsom men ekstremt langsom.

Husker du at lukke dine connection objekter med:
objConn.Close
objConn = Nothing

og dine recordsets med:
objRS.Close
objConn = Nothing


Og er din SQL server sat korrekt op? Se evt. på:
<http://msdn.microsoft.com/library/techart/msdn_sql7perftune.htm >
<http://www.sql-server-performance.com/>

--
Jakob Andersen



Martin Rise Christen~ (22-02-2001)
Kommentar
Fra : Martin Rise Christen~


Dato : 22-02-01 20:50


"Jakob Andersen" <jakob@andersen.as> skrev i en meddelelse
news:uscl6.31206$2w6.522069@twister.sunsite.dk...
> "Martin Rise Christensen" <martin@rise.dk> wrote
> > Jeg har netop oversat en side fra at kører op mod en MS Access database
og
> > ændret til at kører op med en sql server - hvilket også virker - MEN den
> er
> > blevet ikke bare langsom men ekstremt langsom.
>
> Husker du at lukke dine connection objekter med:
> objConn.Close
> objConn = Nothing
>
> og dine recordsets med:
> objRS.Close
> objConn = Nothing
>
>
> Og er din SQL server sat korrekt op? Se evt. på:
> <http://msdn.microsoft.com/library/techart/msdn_sql7perftune.htm >
> <http://www.sql-server-performance.com/>
>
> --
> Jakob Andersen
>
>

Nej jeg får godtnok ikke lukket mine objekter, det vil jeg straks prøve. Har
det virkelig noget at sige mht. performance?

Tak for hjælpen.

Martin Rise Christensen



Allan Ebdrup (24-02-2001)
Kommentar
Fra : Allan Ebdrup


Dato : 24-02-01 14:49

"Martin Rise Christensen" <martin@rise.dk> skrev i en meddelelse
news:G3el6.31406$2w6.536621@twister.sunsite.dk...
>
> "Jakob Andersen" <jakob@andersen.as> skrev i en meddelelse
> news:uscl6.31206$2w6.522069@twister.sunsite.dk...
> > "Martin Rise Christensen" <martin@rise.dk> wrote
> > > Jeg har netop oversat en side fra at kører op mod en MS Access
database
> og
> > > ændret til at kører op med en sql server - hvilket også virker - MEN
den
> > er
> > > blevet ikke bare langsom men ekstremt langsom.
> >
> > Husker du at lukke dine connection objekter med:
> > objConn.Close
> > objConn = Nothing
> >
> > og dine recordsets med:
> > objRS.Close
> > objConn = Nothing
> >
>
> Nej jeg får godtnok ikke lukket mine objekter, det vil jeg straks prøve.
Har
> det virkelig noget at sige mht. performance?

Hej Martin

..Close er altid en god ting, så kan du få frigivet din connection til din
connectionpool, hvis du vil gøre noget ud af scaleability kan du kigge på
MSDN.
Set blah = Nothing har mest betydning hvis du kører under IIS5. Under IIS4
kører garbagecollectoren alligevel ikke før Page_OnEnd. Dvs. dine objekter
bliver alligevel.først frigivet når siden er færdig.

MEN, det er rigtig god programmeringsskik at lukke sine forbindelser og
frigive sine objekter, så du bør gøre det under alle omstændigheder.

Mit bud vil være at dit problem skyldes din opsætning af SQL server, der er
sikkert noget permission checking eller netværks problemer af en slags, har
du checket eventloggen for at se om der kommer nogle fejl ?

Hvis du alligevel gerne vil lære mere om scaleability er der et par links
her:
<http://msdn.microsoft.com/library/default.asp?URL=/library/techart/windnami
stakes.htm>
<http://msdn.microsoft.com/library/default.asp?URL=/library/techart/d5perfov
er.htm>

MVH
Allan Ebdrup, 10-4 ApS
http://www.ti-fire.dk/





Stig Johansen (24-02-2001)
Kommentar
Fra : Stig Johansen


Dato : 24-02-01 17:50

Hej.


"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:978e4r$4dd$1@news.cybercity.dk...
> "Martin Rise Christensen" <martin@rise.dk> skrev i en meddelelse
> news:G3el6.31406$2w6.536621@twister.sunsite.dk...
> >
> > "Jakob Andersen" <jakob@andersen.as> skrev i en meddelelse
> > news:uscl6.31206$2w6.522069@twister.sunsite.dk...
> > > "Martin Rise Christensen" <martin@rise.dk> wrote
> > > > Jeg har netop oversat en side fra at kører op mod en MS Access
> database
> > og
> > > > ændret til at kører op med en sql server - hvilket også virker - MEN
> den
> > > er
> > > > blevet ikke bare langsom men ekstremt langsom.
> > >
> > > Husker du at lukke dine connection objekter med:
> > > objConn.Close
> > > objConn = Nothing
> > >
> > > og dine recordsets med:
> > > objRS.Close
> > > objConn = Nothing
> > >
> >
> > Nej jeg får godtnok ikke lukket mine objekter, det vil jeg straks prøve.
> Har
> > det virkelig noget at sige mht. performance?
>
> Hej Martin
>
> .Close er altid en god ting, så kan du få frigivet din connection til din
> connectionpool, hvis du vil gøre noget ud af scaleability kan du kigge på
> MSDN.
> Set blah = Nothing har mest betydning hvis du kører under IIS5. Under IIS4
> kører garbagecollectoren alligevel ikke før Page_OnEnd. Dvs. dine objekter
> bliver alligevel.først frigivet når siden er færdig.
>
> MEN, det er rigtig god programmeringsskik at lukke sine forbindelser og
> frigive sine objekter, så du bør gøre det under alle omstændigheder.
>
> Mit bud vil være at dit problem skyldes din opsætning af SQL server, der
er
> sikkert noget permission checking eller netværks problemer af en slags,
har
> du checket eventloggen for at se om der kommer nogle fejl ?

For en god ordens skyld, vil jeg lige nævne, at MSSqlserver IKKE er en fil
som access. Rettigheder bliver sat på systemniveau.

Typisk fejl ved migrering fra FIL til RDMS er, at man benytter en 'table
approach' mod databasen.
Eksempelvis "select * from tabel". osv.

Lave et fornuftig DB design, optimer forespørgsler, udtag altid den
'billigste' ressource, kig på fast forward only cursors.

Når det er lavet, vil du finde ud af, at MSSQLserver 'sparker røv'.

--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk





Allan Ebdrup (26-02-2001)
Kommentar
Fra : Allan Ebdrup


Dato : 26-02-01 00:51

"Stig Johansen" <stig@w3data.dk> skrev i en meddelelse
news:_CRl6.39226$2w6.744476@twister.sunsite.dk...
> Hej.
> "Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
> news:978e4r$4dd$1@news.cybercity.dk...
[klip]
> > Mit bud vil være at dit problem skyldes din opsætning af SQL server, der
> er
> > sikkert noget permission checking eller netværks problemer af en slags,
> har
> > du checket eventloggen for at se om der kommer nogle fejl ?
>
> For en god ordens skyld, vil jeg lige nævne, at MSSqlserver IKKE er en fil
> som access. Rettigheder bliver sat på systemniveau.
>
> Typisk fejl ved migrering fra FIL til RDMS er, at man benytter en 'table
> approach' mod databasen.
> Eksempelvis "select * from tabel". osv.
>
> Lave et fornuftig DB design, optimer forespørgsler, udtag altid den
> 'billigste' ressource, kig på fast forward only cursors.
>
> Når det er lavet, vil du finde ud af, at MSSQLserver 'sparker røv'.

Hej Stig
Jeg ved ikke helt om denne kommentar er mindet på mig, men da du svarer på
mit indlæg tager jeg udgangspunkt i det.

Det jeg mener med at checke permissions og netværksproblemer er de
permissions der er på netværksadgang, opsætningsproblemer i protokoller,
bugs og alle de 1.000 andre ting der kan gå galt når man konfigurer en
Server eller to.

Min pointe er at et udtræk fra MSSQL server under normale omstændigheder
ikke bør tage længere tid end det tilsvarende udtræk fra Access, medmindre
der er noget der er sat forkert op.
Derfor tror jeg det kunne være smart at checke eventloggen på både frontend
og DB server og checke opsætningen igen.

De links jeg havde i bunden af min post indeholder praktiske tests og
gudelines for software arkitektur til at bygge gode webapplikationer dvs.
både med god performance, god skalerbarhed, nem vedligeholdelse, nem videre
udvikling osv. med Windows DNA, som typisk er IIS med ASP, COM(+) og MSSQL
Server.
Hvis jeg tager fejl og den oprindelige skrivers problem vitterligt er en
software design fejl, vil jeg anbefale at kigge de guides igennem jeg
linkede til og hive SQL Profileren op ad lommen. (det vil jeg også anbefale
alligevel, men det løser nok ikke det oprindelige problen

Jeg er ikke helt sikker på hvad du mener med 'table approach'. Hvis du mener
normalisering af databasen er det vel ikke noget man først bør gøre når man
flytter tim MS SQL Server ? Hvis du mener indpakning af tabelleren i et Data
Access Layer, typisk vha. stored procedures, er jeg enig. Hvis du mener
noget helt tredie må du lige specificere det lidt nærmere for mig.

Jeg er fuldstændig enig i at MS SQL Server "sparker røv".
Jeg har aldrig prøvet at MS SQL Server var langsommere end Access.

MVH
Allan Ebdrup.
--------------
http://www.ti-fire.dk



Stig Johansen (26-02-2001)
Kommentar
Fra : Stig Johansen


Dato : 26-02-01 06:15

Hej.


"Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
news:97c5ok$1vf0$1@news.cybercity.dk...
[klip]
> Hej Stig
> Jeg ved ikke helt om denne kommentar er mindet på mig, men da du svarer på
> mit indlæg tager jeg udgangspunkt i det.
>

Det var bare ment som generelle betragtninger.

> Det jeg mener med at checke permissions og netværksproblemer er de
> permissions der er på netværksadgang, opsætningsproblemer i protokoller,
> bugs og alle de 1.000 andre ting der kan gå galt når man konfigurer en
> Server eller to.

Du har ret i, at hvis spørgerens problem er at connection tager længere tid,
så kan der være tale om netværksproblemer.

>
> Min pointe er at et udtræk fra MSSQL server under normale omstændigheder
> ikke bør tage længere tid end det tilsvarende udtræk fra Access, medmindre
> der er noget der er sat forkert op.

Prøv elsempelvis at lave en 'select * from tabel' med en clienside cursor.

> Derfor tror jeg det kunne være smart at checke eventloggen på både
frontend
> og DB server og checke opsætningen igen.
>
> De links jeg havde i bunden af min post indeholder praktiske tests og
> gudelines for software arkitektur til at bygge gode webapplikationer dvs.
> både med god performance, god skalerbarhed, nem vedligeholdelse, nem
videre
> udvikling osv. med Windows DNA, som typisk er IIS med ASP, COM(+) og MSSQL
> Server.
> Hvis jeg tager fejl og den oprindelige skrivers problem vitterligt er en
> software design fejl, vil jeg anbefale at kigge de guides igennem jeg
> linkede til og hive SQL Profileren op ad lommen. (det vil jeg også
anbefale
> alligevel, men det løser nok ikke det oprindelige problen
>
> Jeg er ikke helt sikker på hvad du mener med 'table approach'. Hvis du
mener
> normalisering af databasen er det vel ikke noget man først bør gøre når
man
> flytter tim MS SQL Server ? Hvis du mener indpakning af tabelleren i et
Data
> Access Layer, typisk vha. stored procedures, er jeg enig. Hvis du mener
> noget helt tredie må du lige specificere det lidt nærmere for mig.
>

Det var nok et dumt udtryk. Det jeg mener, er, at mange laver applikationer,
hvor man synes det er smart at 'bladre' i resultatsættet, og opdatere mere
eller mindre live. Det resulterer i uforholdsmæssigt stort ressourceforbrug
på serveren. Udtrykket 'table' stammer fra min miljøskade inden for bla.
Delphi verdenen, hvor man opererer med Tables og Queries.

--
Med venlig hilsen/Best Regards
Stig Johansen - stig@w3data.dk
W3 Data - mailto@w3data.dk





Allan Ebdrup (26-02-2001)
Kommentar
Fra : Allan Ebdrup


Dato : 26-02-01 12:01

"Stig Johansen" <stig@w3data.dk> skrev i en meddelelse
news:DDlm6.1297$dD.56891@twister.sunsite.dk...
> "Allan Ebdrup" <ebdrup@ti-fire.dk> wrote in message
> news:97c5ok$1vf0$1@news.cybercity.dk...
> [klip]
> > Min pointe er at et udtræk fra MSSQL server under normale omstændigheder
> > ikke bør tage længere tid end det tilsvarende udtræk fra Access,
medmindre
> > der er noget der er sat forkert op.
>
> Prøv elsempelvis at lave en 'select * from tabel' med en clienside cursor.

Den slags forespørgsler "jeg" skam mange af hver dag, bare i tabeller der
ikke kan blive alt for store (og ikke med *)
Hvis vi snakker om et korrekt opsat 100 Mbit netværk skal du op på et
seriøst stort udtræk (byte size) før du kan mærke forskel på om du har MSSQL
på samme server eller en seperat server.Ved små udtræk gør alt alligevel så
hurtigt at vi snakker om millisekunder, men min påstand er at netværks
transporttiden, ved store udtræk, er meget lille sammenlignet med hvad det
tager for MSSQL server at lave udtrækket.
Og hvis udtrækket så samtidigt kører hurtigere på Access lugter jeg stadig
en opsætnings-rotte

> Det var nok et dumt udtryk. Det jeg mener, er, at mange laver
applikationer,
> hvor man synes det er smart at 'bladre' i resultatsættet, og opdatere mere
> eller mindre live. Det resulterer i uforholdsmæssigt stort
ressourceforbrug
> på serveren. Udtrykket 'table' stammer fra min miljøskade inden for bla.
> Delphi verdenen, hvor man opererer med Tables og Queries.

Jeg er stadig ikke helt sikker på hvad du mener, mener du at det skal være
muligt at have forholdsvis statiske databaser som består af udtræk fra den
"rigtige" database til præsentation, og at man ikke skal lave "paging". Hvad
er det mere præcist du mener man ikke skal gøre og ikke mindst: Hvorfor
koster det performance/scaleability når man gør det? Hvordan undgår man de
problemer du snakker om systematisk?

Jeg er nysgerrig.

MVH
Allan Ebdrup, 10-4 ApS
www.ti-fire.dk



Martin Rise Christen~ (26-02-2001)
Kommentar
Fra : Martin Rise Christen~


Dato : 26-02-01 18:20

Jeg har nu løst problemet - det lå på den enkelte klient, når man lavede
selv en simpel forespørgsel, med f.eks. query analyze, tod den også op mod 2
sekunder, samt belastede serverens cpu helt op til 100%.

Jeg flyttede nu hele applikationen til en anden server, og så perfomede det
helt perfekt. Nu mangler jeg bare at finde ud af hvad der går galt på den
enkelte klient, men det kommer nok også - kommer tid kommer råd.


Tak for hjælpen.

Mvh,

Martin Rise Christensen




Stig Johansen (27-02-2001)
Kommentar
Fra : Stig Johansen


Dato : 27-02-01 11:59

Hej.
"Martin Rise Christensen" <martin@rise.dk> wrote in message
news:Jewm6.2013$dD.128687@twister.sunsite.dk...
> Jeg har nu løst problemet - det lå på den enkelte klient, når man lavede
> selv en simpel forespørgsel, med f.eks. query analyze, tod den også op mod
2
> sekunder, samt belastede serverens cpu helt op til 100%.
>
> Jeg flyttede nu hele applikationen til en anden server, og så perfomede
det
> helt perfekt. Nu mangler jeg bare at finde ud af hvad der går galt på den
> enkelte klient, men det kommer nok også - kommer tid kommer råd.
>

Start med at tjekke MDAC versionerne.

mvh
Stig Johansen.




Søg
Reklame
Statistik
Spørgsmål : 177557
Tips : 31968
Nyheder : 719565
Indlæg : 6408868
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste