Brug af alle kerner i en CPU

Mit bud er at de i IIS7 har gjort application pool flertrådet.

IIS6 køre formentligt hver application pool i sin egen tråd og derfor er det med IIS6 vigtigt at få hver side givet sin egen application pool (er 95% sikker har ikke gidet undersøge det eftersom det løste det opståede problem at køre med flere pools)

Hvis hver CPU er ligeligt belastet køre det så optimalt som muligt for så kan det udnytte alle kerner og så kan der være flere fordele ved at køre alle kerner med ca. samme load end kun at køre på en enkelt kerne.

Server apps har kunnet udnytte flere CPU'er og dermed ogssa flere kerner i aartier.

Det du citerer er saadan noget som bliver fremfoert af folk der betragter sig som IT professionelle fordi de er gode til WoW eller CS.

IIS, SQLServer har understoettet flere CPU'er/kerner siden foerste version.

Arne, vil det sige at det jeg får ud af at lave flere tråde i min ASP.Net app ikke giver noget performance server-mæssigt, men udelukkende for den enkelte side-indlæsning?

arne nu er version2 en side af IT prof folk og de fleste der bruger den side ofte ved udemærket godt at server ting kan køre på flere kerner.

Jeg vil tillade mig at stille spørgmålstegn til om IIS6 køre application pool trådet. Vi har på min arbejdsplads prøvet at flere sider der kørte på samme server blev tunge og svarede langsomt. Af en eller anden grund kørte de på samme application pool. Efter vi har skiftet til en side en applikation pool (hvilket det IMO også bør være) er problemet forsvundet og vi kan visuelt se på serveren at belastningen nu er bedre fordelt på kernerne.

Der ud over tvivler jeg på at IIS1 til windows 3.51 understøttede flere kerner eftersom windows 3.51 næppe har understøttet flere kerner. Men det er muligvis bare mig der er pessimist nu ;)

Mvh
HE

re #3)

Du boer aldrig selv starte traade i en ASP.NET web app.

Men ASP.NET vil koere i mange traade saa den kan udnytte mange kerner.

Arne selvfølgelig kan man selv bruge tråde. Faktisk kan man med fordel bruge tråde til visse opgaver især de tunge af dem.

ASP.NET lader hver bruger køre i en tråd for sig men til tider kan man have behov for opgaver der enten tager lang tid eller er tunge beregningsmæssigt og der kan man med fordel splitte det op i flere tråde.

Arne:

Hvis jeg ønsker at vise en side med et produkt,. men samtidig opdatere en database med forskellige ting omkring denne visning (sidst set, hvem har set etc.) er der vel ingen grund til at lade "hovedtråden" vente på at denne opdatering foregår?

re #4)

Hver application pool har sin egen thread pool med et antal traade.

Og ja - NT 3.51 understoettede flere kerner (dengang var det saa en kerne per socket, men det er softwaren ligeglad med).

re traade)

Det er et klassisk problem. Der sider en server admin og bruger tid paa at konfigurere det optimale antal traade til ASP.NET og saa viser det sig at diverse web programmoerer bare starter et antal traade selv og man ender med daarlig performance.

Antal traade i ASP.NET, antal connections til SQLServer er drifts opgaver ikke software opgaver.

Hvis der skal koeres noget asynkront, saa smid det i en message queue og lad noget processe derfra med et fixed antal traade.

Som en lille positiv side gevindst giver det ogsaa en mere robust app, fordi det er meget svaert at recover fornuftigt hvis der har vaeret nogle web app startede traade igang med noget og application pool recycler.

tid at få afsluttet her?

Ja, undskyld ventetiden