Hallå!

Som alla vet så är "hög belastning" ett väldigt abstrakt uttryck. Vad menas egentligen med hög belastning?

I skrivande stund har jag 360 aktiva sessioner och min processor snittar på ca 3,2% och 7,1 requests / sekund. Detta kan väl det knappast kallas hög belastning, eller?

Tja, jag har många sessioner, rätt många requests men nästan ingen CPU-usage. Så vad tycker NI är hög belastning? 75% CPU, eller 50 requests/sek, eller 1500 aktiva sessioner? Rätt intressant att få reda på olika åsikter.

Jag tycker att hög belastning är när processorn ligger konstant på ca 60-75%.

Applikationen är skriven i ASP.NET (VB) och databasen är SQL Server 2000. All logik (databastransaktioner o så) går genom en komponent skriven i VB.NET, så själva ASP.NET-applikationen gör aldrig databasanrop eller transaktioner.

Hårdvara:
3st HP bladservrar med följande konfig i varje:
2x3.06GHz Xeon(HT), 2GB RAM, 2x72GB SCSI 15K (speglade med RAID-kort) 3xNIC 1Gbps
Dessa sitter i en network load balancing och hanterar bara IIS (applikationen inklusive komponenten)

SQL Server körs på en 4-vägsmaskin (med HT) och 4GB RAM. Massa snabba 15K U320-diskar i RAID5.

Jag vill poängtera att jag inte frågar efter hjälp eller så, jag har alltså inga problem i min applikation. Vill bara starta en diskussion om vad hög belastning egentligen är.

Din åsikt är önskad!

MVH
Fredrik

Till Pelle: Har du lust att dela med dig om lite prestanda/belastning och hårdvaruinfo för pellesoft.se?

Du jag kan faktiskt inte svara på detta mer än att det är två windows 2003 servrar, Pentium 4, 2.66 ghz, 1gb minne på varje. Min cpu ligger oftast på 2-4%. Just nu 9862 handles, 495 threads och 40 processer på webbservern.

Bandbredden är nog ca 150mbit. Loggfilerna blir ca 100mb/dygn (~2,5gb/månad) på webbservern så det är rätt hög aktivitet trots allt. Kör 5 sajter på samma server och applikationerna är blandade .net och asp.

Jag håller med att hög är 60-70%. Du nämner inte lagrade procedurer men då går vi in på andra frågor - men jag har har lagrade procedurer i 99,5% av alla anrop till db:n.

Tack för infon.

Vi har faktiskt inga stored procedures i databasen. All logik och allt som sker mot databasen är helt och hållet styrd från komponent.

Intressant fråga faktiskt!

Låt oss anta att vi skulle kunna definiera "hög belastning" som antal requests/sekund. Vi skulle ganska snart inse att det inte går att få en klar definition, utan tvingas säga något i stil med "webbservern är under hög belastning för att den har många användare". Detta kommer dock att vara relativt webbservern (en "dålig" webbserver kommer naturligtvis inte klara av att hantera lika många användare som en "bra"), och därmed blir det ingen bra definition.

Jag skulle istället vilja säga att "hög belastning" på webbservern är relativt hårdvaran (som inkluderar, men inte enbart beror på, processorn).

Dessutom är det roligare att säga "Det är hög belastning på webbservern för vi har många besökare", till chefen, än att säga enbart "Webbservern är högt belastad". Jag skulle nämligen vilja säga att det inte enbart beror på antal användare, utan även på webbapplikationen. Det skulle därmed (enligt mig) gå att säga till chefen: "Det är hög belastning på webbservern för att konsulterna vi anlitade skrev dålig kod".

En webbserver klarar av att hantera betydligt fler requests/sekund om webbservern endast levererar statisk html, än dynamiska sidor, vilket tycker jag stärker påståendet att även webbapplikationen kan orsaka "hög belastning".

Sedan kan det diskuteras om även bandbredden ska inkluderas i "hög belastning". Om användaren besöker websajten under en tidpunkt när bandbredden inte räcker till, så kommer användaren att uppleva besöket som långsamt, och skulle kunna säga att det var orsakat av "hög belastning". För användaren var det också så, eftersom nätverkskomponenterna var "högt belastade", men däremot hade webbservern det lugnt.

Så jag tycker att "hög belastning" innebär att webbservern (om vi pratar om hög belastning för enbart webbserver) är när webbservern har för mycket att göra, och tvingas köa requesten onormalt länge. (onormalt länge om det är "för hög belastning").

Det låter illa Fredrik. Men ni kanske inte har krav på prestanda eller ens Oracle eller SQL-server.

Jag skulle nog definiera hög belastning så att när en användare nekas en förfrågan, eller i allmänhet tycker att det går långsamt är webbservern högt belastad, eftersom det är så många olika faktorer som kan spela in. Sedan kan man diskutera vilket som ger mest prestandavinst att förbättra...

Hur mycket prestandavinst får man om man kör Stored Procedures istället för som Fredrik via en komponent? En komponent antar jag är ett klassbibliotek kompilerat som en DLL-fil, där du kan få datasets returnerade och liknande?

Tack för era inputs. Det är precis dessa diskussioner jag vill föra.

Vi använder inte SP:s utan kör klassiska SQL-statements direkt från komponenten (SELECT, INSERT, DELETE, UPDATE). Komponenten är ju kompilerad DLL och vi har höga krav på prestanda. Vi har kanske 400 transaktioner per sekund (sökningar, orderläggning, inloggningar, nya kunder, nya artiklar o gud vet allt). Eftersom detta är en komponent som distribueras till olika företag (flera olika SQL-servrar) har vi valt att ha all logik i komponent. SQL-server är "bara" data storage. Vi hanterar alla låsningar i vårt eget system. Vi har testat med SP:s men har inte funnit någon prestandavinst eller ökad funktionalitet. Vi tar ut allt data som Collections vilket vi finner mycket smidigt. Vi har skrivit egna "datagrids" osv. Vi använder gigabitnät mellan webservrarna och SQL-servern.

Många skriker rakt ut när de hör att man inte kör SP:s men vi har inga prestandaproblem och vi känner själva att vi har större kontroll på vad vi gör. Om vi behöver ändra en query så gör vi det på ett ställe. När komponenten replikeras ut så har den de nya funktionerna och vi behöver inte fundera på om databasen har rätt SP. Om vi skulle ändra en SP så måste vi vara 100 på att klienterna + alla webbar har den senaste komponenten också, om ni förstår hur jag menar.

Jag tycker att Kristofer Gäfverts inlägg är en mycket intressant reflektion. Fler kommentarer önskas.

Det är inget fel att lägga sql-satser i komponenter men skillnaden där blir att sql-satserna måste kompileras om varenda gång de anropas. Om det är lagrade procedurer finns dessa redan kompilerade och innehåller en s.k executionplan och kan därmed även cachas. Vad gäller kompabilitet spelar det nog inte så stor roll, du måste ju ändå skicka med en databas och dess inställningar.

Fast om man kör SQL Server 2000 så kommer även "vanliga" SQL-satser att lagras i procedure cache - och följdaktligen optimeras. Det är när man har stora batcher eller mycket komplexa selectsatser som man KAN tjäna på en procedur.
Procedurernas främsta vinst (generellt) är att de kapslar anrop = det blir svårare att skriva/anropa fel.

/micke

Sedan är det väl också så att normalt är det olika personer som göra olika delar av applikationer. En gör GUI, en logik, en komponenter, en databas osv. DÅ är det naturligtvis enklare att DB-admin kör sitt race och de andra sitt.

Hög belastning måste vara relativt kapaciteten. Det mesta som man kan få ut av performance monitor kan vara intressant här. Processoranvändning, minnesanvändning, disk-io, diskköer för skrivning och diskköer för läsning är sånt som man kan kolla på. Jag vet inte om disk-io och diskköer har någon betydelse på webbservern, men på sql servern kan sånt påverka prestanda.

Lagrade procedurer har stora fördelar för säkerheten. Databasanvändaren som applikationen använder måste inte ha behörighet till några tabeller eller dylikt i databasen utan endast de procedurer som används (förutsatt att inte dynamisk sql används i procedurerna). Dessutom löper man minskad risk för att drabbas av sql injection.
Vad gäller applikationens arkitektur finns det också fördelar med att använda lagrade procedurer; Man har ett bestämt gränssnitt mellan programkomponenter och databas, som inte nödvändigtvis måste ändras om man av någon anledning skulle ändra datamodellen (tabellstrukterer mm). Alltså inkapsling, precis som Micke skrev.

Sedan, när de gäller att lagrade procedurer är förkompilerade så är det så att detta är beroende av hur många rader som returneras. Så om antalet rader som en procedur returnerar skiljer sig åt mycket mellan olika anrop kommer omkompileringar att göras under körning.

Sist vill jag varna för att använda RAID5 på en sql server om det inte absolut behövs en sådan driftsäkerhet. RAID5-system ger stor overhead vid skrivning till databasen, och db-loggen skrivs det ju till konstant. RAID1 eller RAID1+0 är betydligt effektivare och har tillräckligt hög driftsäkerhet för det mesta. Vill man absolut ha RAID5 för databasen borde man åtminstone kunna flytta loggen till ett annat disksystem.

/Pelle