Okej, först vill jag bara säga att .Net inte är min grej alls, därför kan denna fråga kanske bli lite luddig.
I alla fall, på jobbet håller vi på att öka på prestandan på en applikation skriven i VB.Net. Jag har nosat runt lite här på forumet och sett att det inte verkar vara rekommenderat att köra odbc, vilket vi kör med. Men vad är alternativen? Stor tyngd läggs vid att det skall gå så snabbt som möjligt, vi har idag transaktioner som tar allt ifrån 0 till ~30 ms och det är inte tillräckligt snabbt (<10 ms är målet). Vi går givetvis igenom våra stored procedures och resten av programmet i övrigt men om man kan vinna några millisekunder på att lämna odbc bakom sig är det iaf en liten bit på vägen.
Det är en MS SQL Server 2000 längst där bak och de queries som körs allra oftast är utan tvekan update-queries om det har ngn betydelse.
Om du använder dig av MS SQL Server, så har du "mycket" att hämta prestanda mässigt på att lämmna ODBC och använda dig av de special skrivna SQL dataklasser som finns i .NET Framework.
Hur mycket man vinner vet jag inte, men det skall vara mycket i databaskopplingens värld, vilket kanske kan ge er någon millesekund i programmetsvärld.
Men ODBC är väl den drivrutin som är långsammanst och minst rekomenderad att använda, där är ju OleDB att föredra istället.
Nu tror jag inte man vinner så jättemycket på det, utan det kanske är mer intressant och se övrig kod, för oftas är det där man kan hämta vinster, eller indexerna i databasen, de kan göra underverk...
Om ni använder er av DataTable's och DataSet's försök gör om det till en mer traditionell arkitektur, DataTable och DataSet tar en del prestanda, iallfall i 1.1:an.
En annan bra sak är att köra SQL profiler när din applikation körs under nörmal drift. Kör dock inte alltför länge för det påverkar prestandan att köra profiler :) Resultatet av en körning är värt mödan eftersom du kan få ett hum om vilka procedurer du ska optimera. Du kan tex få fram vilka procedurer som tar längst tid, hur mycket cpu de tar, hur ofta en procedur används m.m.
Sen kan det vara vettigt att kanske se över detta med index.
Vi får se om vi hinner optimera mera den här veckan. Hur som haver hör jag av mig när jag vet om det blev ngn mätbar skillnad. Det är inte alls säkert, om ens troligt, att det är där flaskhalsen ligger. Vi får se. :)
Det blev en ganska så stor skillnad, nu mätte vi inte exakt men vi hann med mellan 50 och 100 fler transaktioner per sekund med OleDB. Helt klart godkänt. :)
men vi hann med mellan 50 och 100 fler transaktioner per sekund med OleDB.
Om du använder SQL Server så skall du INTE använda OleDB, det finns specialla klasser framtagna för att låta .NET kommunicera med MS SQL Server, där finns mer prestanda att hämta, hur mycket vet jag inte, men den är snabbare än OLEDB...
Om du använder SQL Server så skall du INTE använda OleDB, det finns specialla klasser framtagna för att låta .NET kommunicera med MS SQL Server, där finns mer prestanda att hämta, hur mycket vet jag inte, men den är snabbare än OLEDB...
Det behöver du inte.. Istället för att använda System.Data.OledDbData så använder du System.Data.SqlData eller vad de nu heter, du hittar de under System.Data fungerar precis som OledB. Men börjar med SQL istället för Oledb: SqlConnection, SqlCommand, osv osv...
Ska kika på det när tillfälle finns. Vi flyttade till nya lokaler idag så det dröjer nog tills nån gång i mitten av nästa vecka, men lita på att jag hör av mig ang. resultatet.
252 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
