Hej!

Detta är en ganska luddig fråga men jag ställer den iaf. :)

Om man tänker sig ett system som ständigt kör selectfrågor. Inga tunga saker med cursors, temptabeller eller liknande utan bara raka select. Hur många är då "för många" på en normal server med t.ex. en hyffsad processor, en gig minne etc.

Självklart förstår jag att man bör ha så få förfrågningar som möjligt men var ligger en bra gräns? 1000 frågor/sek? 1000 frågor/min? Mer eller mindre?

Mvh
Peter

det jag reagerade starkt på var <b>en normal server med t.ex. en hyffsad processor, en gig minne etc. </b>... En produktionsserver med en processor och bara ett gig minne? Det har inte varit normala servrar på något ställe jag jobbat på under de senaste 5 åren och enbart haft SQL server som databas... ;-)

Hehe, nej det kanske var lite i underkant. Om vi justerar upp det lite då..? :)

Peter,

Det är en omöjlig fråga att ställa som du gör, och därmed omöjlig att svara på.

Varenda del av datorns hårdvara och hur denna är konfigurerad har betydelse. Antalet processorer och deras hastighet, typ och mängd av minne och deras hastighet, typ och mändg hårddisk och deras hastighet osv...

Även med dessa faktorer kända så finns inget svar. Hur stor är databasen totalt sett? Hur stora är respektive tabell? Finns det några index? Är det optimerade för den aktuella frågeställningen? Hur väl är data organiserat och normerat utifrån behovet? Hur mycket av datorns hårdvara har allokerats för de olika delarna?

Vidare är hur ser selectfrågorna ut? Vilken komplexitet finns? Är det läsning från en tabell med 10 rader? Eller är det kombinerande av data från många tabeller med vardera många tusen eller hundratusen rader?

Sedan är frågan om det sker flera parallella läsningar som måste hanteras eller om det kommer från enbart en connection? Hur är det med skrivningar? Olika typer av låsningar?

Osv...

Och så slutligen, om du lyckas formulera en väl avgränsad fråga, hur intressant är svaret? Om du vet att vid en viss tidpunkt med vissa förutsättningar sp lyckades man med x läsningar per sekund. Men hur väl speglar det ett genomsnittslig behov? Och hur är det med toppbelastningar? Ett genomsnitt är kanske bara genomsnitt på papperet med många operationer vissa stunder för att däremellan ha långa väntetider?

Och även om med en bra formulkerad fråga och ett precist svar är det svårt att dra verkliga slutsatser eller utifrån det göra beräkningar för andra scenarion...

* * *

Tyvärr hjälper väl knappast mitt svar här för din fråga, men tanken är att få dig att inse hur komplext det kan vara och fundera på om du verkligen har nytta av att ställa frågan? Kanske skall du ha ett helt annat angreppssätt på din frågeställning?

// Johan

Hej Johan,

När jag tänkt efter lite grann så är det ju precis som du säger. En omöjlig fråga att ställa och en ännu omöjligare fråga att svara på. Eller iaf. svara på så att värdet att svaret blir intressant. Hur man än gör så måste ju applikationen stresstestas med det tilltänka arbetssättet ändå.

Men tack så hemskt mycket för att du svarade!

Next up. Stresstest! :D

Mvh
Peter

Det man möjligen kan säga är att under goda förhållanden så ligger resultatet betydigt närmare 1000 frågor/sekund än 1000 frågor/minut.

Det bästa du kan göra är helt enkelt att stresstesta din lösning. Det går inte att säga något generellt om din lösning eftersom vi inte vet hur den ser ut. Kolla in programmet Microsoft Application Center Test som följer med Visual Stuido 2003 Enterprise. Bekanta dig även med SQL server Profiler.

Det absolut vanligaste felet som utvecklare gör är att de glömmer INDEXERA de kolumner som används i WHERE-villkor. Att göra detta är A och O, det kan förbättra prestandan och därmed skalbarheten (hur mycket applkationen orkar per sekund) med en faktor på flera tusen gånger! Detta tål att upprepas.. Man kan spara *mycket pengar* om man tittar på detta innan man börjar köpa ny hårdvara...

Här kan du se lite olika SQL server benchmarks http://www.microsoft.com/sql/evaluation/compare/benchmarks.mspx