ASP.net architectuur.

[MasterTweaker]

Ik heb even een vraag over hoe de ASP.net architectuur nou precies werkt. Hieronder is een schematisatie te zien van de ASP.net architectuur:


(De bron: http://learn.iis.net/page...tion-to-iis-architecture/)

Maar goed nu heb ik eigenlijk de volgende vragen waarvan ik hoop dat iemand dat hier weet:

-Stel je voor dat je een ASP.net applicatie installeert in ISS 7.0 op een Windows 2008 server. Als er nu dan bijvoorbeeld 100 mensen tegelijkertijd van de applicatie gebruikmaken heb je dan ook honderd W3WP.exe processen lopen op deze server? Of is er altijd maar 1 W3WP.exe en heb je dan 100 interne modules ( zie de schematisatie )?

Ik vond bijvoorbeeld deze schematisatie:


(bron: http://technet.microsoft....c737616%28v=ws.10%29.aspx)
Hier van uitgaande lijkt het mij dan dat er gewoon 100 W3WP.exe processen actief zijn bij 100 gebruikers, maar helemaal zeker hiervan ben ik dus niet.


-Als je nu een aparte database server hebt (MYSQL server), welk proces communiceert daar dan precies mee? Is dat alleen het W3WP.exe proces?

- Is het mogelijk om een ASP.net applicatie te installeren op 1 server waarvan 1000'den mensen tegelijkertijd gebruik maken of heb je dan al snel meerdere servers nodig?

- En heb je om een ASP.net applicatie te draaien op een server nou alleen Windows server 2008 nodig of moet je ook ISS 7.0 apart installeren? Of is dit al standaard meegeïnstalleerd bij Windows server 2008?

[ Voor 7% gewijzigd door MasterTweaker op 05-05-2012 19:09 ]

[TheNameless]

Je moet het zo zien:
- IIS definieert applicaties (zeg maar een website of virtual directory) en appliction pools.
- Per applicatie geef je aan welke application pool je gebruikt (zo kan je bijvoorbeeld verschil maken tussen .NET 2.0 en .NET 4.0 applicaties).
- Een application pool heeft altijd minimaal 1 workerprocess (W3WP.EXE), maar is instelbaar om meerdere te gebruiken. Als je dat doet creeer je een zogehete WebGarden. In de praktijk zal je dat zelden doen trouwens.
- Een workerprocess heeft een threadpool en gebruikt 1 thread voor 1 request (in tegenstelling tot bijvoorbeeld de NodeJS server). Zo kan je dus makkelijk een 1000 tal requests tegelijkertijd afhandelen voor 1 applicatie/website. Door de threads worden dus ook automatisch al je cores gebruikt.

De notie van modules snap ik zelf niet helemaal, maar misschien worden hier applicaties bedoelt.
Het is zo dat je applicatie onder de gebruiker van een app-pool draait, deze moet dan dus ook toegang hebben tot je MySQL server. De gebruiker waaronder je app-pool draait is instelbaar.

IIS 7.0 komt standaard als onderdeel van Windows Server 2008 en is volgens mij te activeren via de Webserver role. Als je Windows 7 gebruikt dan kan je trouwens gewoon ook IIS activeren en er wat mee spelen.

edit: Windows Activation Services word volgens mij alleen gebruikt als je bijvoorbeeld een WCF service wilt hosten via IIS die zijn services aanbied via bijvoorbeeld TCP of UDP. Waarschijnlijk zal je ook WAS moeten gebruiken voor dingen zoals websockets en dergelijke.

[ Voor 21% gewijzigd door TheNameless op 05-05-2012 18:04 ]

[MasterTweaker]

TheNameless schreef op zaterdag 05 mei 2012 @ 17:57:
Je moet het zo zien:
- IIS definieert applicaties (zeg maar een website of virtual directory) en appliction pools.
- Per applicatie geef je aan welke application pool je gebruikt (zo kan je bijvoorbeeld verschil maken tussen .NET 2.0 en .NET 4.0 applicaties).
- Een application pool heeft altijd minimaal 1 workerprocess (W3WP.EXE), maar is instelbaar om meerdere te gebruiken. Als je dat doet creeer je een zogehete WebGarden. In de praktijk zal je dat zelden doen trouwens.
- Een workerprocess heeft een threadpool en gebruikt 1 thread voor 1 request (in tegenstelling tot bijvoorbeeld de NodeJS server). Zo kan je dus makkelijk een 1000 tal requests tegelijkertijd afhandelen voor 1 applicatie/website. Door de threads worden dus ook automatisch al je cores gebruikt.

De notie van modules snap ik zelf niet helemaal, maar misschien worden hier applicaties bedoelt.
Het is zo dat je applicatie onder de gebruiker van een app-pool draait, deze moet dan dus ook toegang hebben tot je MySQL server. De gebruiker waaronder je app-pool draait is instelbaar.

IIS 7.0 komt standaard als onderdeel van Windows Server 2008 en is volgens mij te activeren via de Webserver role. Als je Windows 7 gebruikt dan kan je trouwens gewoon ook IIS activeren en er wat mee spelen.

edit: Windows Activation Services word volgens mij alleen gebruikt als je bijvoorbeeld een WCF service wilt hosten via IIS die zijn services aanbied via bijvoorbeeld TCP of UDP. Waarschijnlijk zal je ook WAS moeten gebruiken voor dingen zoals websockets en dergelijke.

Oke bedankt, nu is het al een stuk duidelijker. Ik vond trouwens net nog deze website waar het ook wel redelijk duidelijk uitgelegd wordt:
http://www.codeproject.co...plication-Life-Cycle-in-D
Hier hebben ze het ook over appdomains die zich weer binnen een w3wp.exe proces bevinden.

Maar is er een maximum verbonden aan hoeveel threads de threadpool aankan, of is dit grotendeels afhankelijk van de hardware? En kan je een ASP.net applicatie bijvoorbeeld ook 5 keer ( of meer ) in aparte Application pools installeren op dezelfde server zodat je alsnog 5 keer meer gebruikers tegelijkertijd aankan of werkt het niet op deze manier, en moet je dan echt een extra server gaan aanschaffen?

[TheNameless]

MasterTweaker schreef op zaterdag 05 mei 2012 @ 18:56:
[...]

Oke bedankt, nu is het al een stuk duidelijker. Ik vond trouwens net nog deze website waar het ook wel redelijk duidelijk uitgelegd wordt:
http://www.codeproject.co...plication-Life-Cycle-in-D
Hier hebben ze het ook over appdomains die zich weer binnen een w3wp.exe proces bevinden.

Maar is er een maximum verbonden aan hoeveel threads de threadpool aankan, of is dit grotendeels afhankelijk van de hardware? En kan je een ASP.net applicatie bijvoorbeeld ook 5 keer ( of meer ) in aparte Application pools installeren op dezelfde server zodat je alsnog 5 keer meer gebruikers tegelijkertijd aankan of werkt het niet op deze manier, en moet je dan echt een extra server gaan aanschaffen?

Een appdomain zullen ze inderdaad wel bedoelen met de term module.

De .NET framework heeft zelf een threadpool met een specifiek maximum die je kunt instellen. Dit is volgens mij een machine-wide pool, dus voor alle .NET applicaties samen, op een machine.
IIS werkt eigenlijk wel een stuk complexer dan dat ik eerst schetste; als een request binnen komt bij IIS word deze eerst op een queue geplaatst. IIS heeft een aantal (in te stellen) threads draaien die van die queue lezen, vervolgens een aantal zaken regelen om vervolgens deze requests op een nieuwe queue te plaatsen.
Deze andere queue word van gelezen door de threadpool van het ASP.NET framework.

Van deze 2 queues valt trouwens ook die maximum size in te stellen, voor dat er requests "weggegooid" worden.

Een .NET applicatie meerdere keren in een app-pool hangen kan niet en heeft eigenlijk ook geen nut, omdat alle requests die binnen komen toch al verwerkt worden door meerdere threads. De hoofd reden om een applicatie in een nieuwe app-pool te hangen is er eigenlijk voor te zorgen dat je andere applicaties niet down gaan als je app-pool gerecycled word. Om er voor te zorgen dat je applicatie altijd up-to-date en goed draait, moet 1 keer in de zoveel tijd de app-pool gerecycled worden. Denk bijvoorbeeld aan wijzigingen in je code, je configuratie of misschien heb je per ongeluk wel een memory-leak geintroduceerd die er anders voor zou zorgen dat je hele server hangt.

Waar ik werk maken we ook gebruik van IIS 7.5 voor de hosting van een SaaS platform. We hebben een groot aantal verschillende applicaties draaien die verschillende loads hebben. Wat we zien is dat je niet zo maar meer threads kan introduceren om de boel te versnellen. Dan treden er teveel context-switches op en wordt de boel weer traag. De opties die je dan hebt om de boel te versnellen zijn:
- de gemiddelde tijd van een request te verkorten (hoe korter een request, hoe meer requests/seconde op een thread)
- I/O heavy requests async te maken d.m.v IAsyncHttpHandler
- extra server kopen

[FlowinG]

Een module is geen appdomain of andersom.
Een appdomain is een term uit .NET (wat in principe los staat van IIS), waarin assemblies geladen worden. Je kan AppDomains een beetje zien alsof het een virtueel proces in een proces is. Een proces kan meerdere appdomains bevatten die ieder weer een of meerdere assemblies geladen hebben (normaal gesproken een dll). Een appdomain wordt bijvoorbeeld vaak gebruikt als een sandbox. Bij normaal gebruik heeft een application standaard een appdomain. Bij geavanceerdere scenario's waarbij je meer zaken wilt scheiden (bijv via een sandbox of plugins), kan je in code runtime een appdomain aanmaken waarin je een assembly laadt. Het voordeel van het gebruik van aparte appdomains is ook nog dat je een appdomain met bijbehorende assemblies kan stoppen/ontladen. Vanuit een appdomain zelf, kan je geen assemblies ontladen (dus een referentie verbreken naar een dll), alleen als het gehele appdomain ontladen wordt.

Een module zoals IIS dat noemt is weer een apart verhaal. Er zijn zowel native modules (vooral kernfunctionaliteit zoals het afhandelen van requests, niet perse http-request, ssl, authenticatie types zoals anonymous, integrated authentication, etc) en managed modules. De eerste draait in IIS en is onderdeel daarvan. De managed modules zijn vooral modules binnen een applicatie en draaien in een eigen appdomain. Zo'n appdomain kan dan geladen zijn met ASP.NET assemblies met zijn met bijbehorende modules.

In het geval van ASP.NET, is een module vaak een assembly met een specifieke functie. Als voorbeeld neem ik een module voor authenticatie. Zodra een request binnen komt in IIS voor een ASP.NET application, dan gaat het request door een pipeline. In die pipeline kan het request langs verschillende modules gaan. Je kan je voorstellen dat ver aan het begin van zo'n pipeline, de authenticatie module aangeroepen wordt, waarna deze controleert op het binnenkomende request valide is.

Naast authenticatie zijn er nog veel andere modules die essentieel zijn: caching, sessie, routing, etc. Feitelijk bestaat alle functionaliteit van ASP.NET ook uit modules.

Zoals eerder genoemd gebruikt IIS/ASP.NET voor elk request een thread. Zodra een request bij IIS binnenkomt, wordt een thread opgestart en de bovengenoemde pipeline doorlopen. Binnen die pipeline worden alle ingeladen managed modules aangeroepen. Deze modules worden ingeladen op verschillende momenten, bijvoorbeeld bij het opstarten van de ASP.NET application (na een iisreset of recycle, je vind in de global.asax vaak wat methodes om het opstarten op te vangen). Het is ook mogelijk om runtime modules te laden, of de web.config te configureren om additionele modules in te laden.

Om nog wat meer te duiden: het door jou bijgevoegde plaatje over de architectuur beschrijft eigenlijk de IIS architectuur, het blokje onder Worker Process waarin Module staat, hoeft geen ASP.NET zijn, maar kan net zo goed PHP voorstellen of een ander type module. ASP.NET staat namelijk los van IIS hoewel het natuurlijk wel 'voor elkaar' gemaakt is (ASP.NET kan ook in een andere webserver draaien: Casini, Apache met mono, IIS Express, etc). Het volgende plaatje van diezelfde website die je noemde, biedt meer inzicht hoe een request binnen IIS verloopt:


Wil je meer weten over ASP.NET pipeline, dan raad ik je om dit artikel eens door te lezen.