ASPNL - Dé informatiebron over ASP en .NET

zaterdag 17 mei 2008

artikelen

<< vorige | overzicht | volgende >>

Overzicht van crashbeveiliging in ASP.NET

Door Charles Carroll
15 januari 2002

ASP.NET is fout-tolerant, kan herstellen van crashes en heeft vele andere geavanceerde eigenschappen. Code met een geheugen lek, een oneindige loop, of die een bron niet (correct) afsluit, zal slechts 1 thread aantasten. Zodra de ASP.NET omgeving een thread ontdekt die vreemd doet, worden nieuwe verzoeken naar nieuwe threads gestuurd, erop toeziend dat de nieuwe verzoeken niet in contact komen met deze verdachte thread. Uiteindelijk zal, nadat het laatste gebruikersverzoek op deze beschadigde thread is doorgevoerd, deze thread vernietigd worden en recyclen.

Code die slecht is, maar waarbij de problemen niet te achterhalen zijn, levern geen problemen op. Eenvoudige directives in een web.config bestand kunnen het vernietigen en recyclen van threads initieren als er problemen worden ontdekt, of zelfs als dat niet zo is (alle threads worden bijvoorbeeld vernietigd na 30 minuten). Threads worden simpelweg vernietigd en gerecycled uit voorzorg. Dit betekent dat SERVERS nooit hoeven te rebooten.

Dus als gebruiker 1 een oneindige loop uitvoert, en het verzoek wordt afgehandeld op Thread3, dan zal het script van de volgende gebruiker worden uitgevoerd op Thread4, en wordt er een plan in werking gezet dat Thread3 zal afbreken en vernietigen.

Een eenvoudige web.config setting (de ASCII/XML configuratie bestanden die alle instellingen bevatten) verzekert je ervan dat het ASP.NET werker proces (het proces met alle threads die code uitvoeren) nooit meer dan een bepaalde hoeveelheid geheugen gebruikt. Als het ASP.NET werker proces meer geheugen gebruikt dan bepaald was, wordt er een nieuw ASP.NET werker proces aangemaakt om nieuwe pagina aanvragen te verwerken, en het oude proces vernietigd nadat die de lopende verzoeken heeft afgehandeld.

My Experiences with ASP.NET PDC bits geeft meer uitleg over de settings in web.config.

Omdat ASP.NET alle pagina opbouw verzorgt en HTML afgeeft aan IIS, wordt IIS het volgende mogelijke mikpunt om te crashen. Het doet dit zodat als ASP.NET is verplaatst naar laten we zeggen Solaris, ASP.NET HTML zou kunnen afgeven aan bijvoorbeeld Apache of iets dergelijks. ASP "Classic" en IIS zijn nauw verbonden. Zie hierover ook het boek ASP Internals van Jon Flanders. ASP.NET en IIS bevinden zich daarentegen niet eens op dezelfde planeet.

In Las Vegas demonstreerde Scott Guthrie hoe ASP.NET een niet werkende website in IIS opmerkte en vervolgens "on the fly" een andere website maakte om verdere aanvragen af te kunnen handelen.

Scott Guthrie, ASP.NET designer, voegt hier het volgende aan toe.
Er zijn een aantal ASP.NET features waarvan ik denk dat ze de betrouwbaarheid en beschikbaarheid verbeteren:

Automatisch detecteren/herstellen van toegang overtredingen
Automatisch detecteren/herstellen van geheugen lekken
Automatisch detecteren/herstellen van thread deadlocks
Mogelijkheid tot configureren van ASP.NET naar een pro-actief herstart proces elke N minuten (zonder dat de gebruiker hier hinder van ondervindt)
Mogelijkheid tot configureren van ASP.NET naar een pro-actief herstart proces elke M verzoeken (zonder dat de gebruiker hier hinder van ondervindt)
Mogelijkheid tot updaten/verplaatsen van actieve DLLs zonder dat de gebruiker hier hinder van ondervindt
Mogelijkheid tot updaten/verplaatsen van configuratie zonder dat de gebruiker hier hinder van ondervindt
Web farm session state (om te verzekeren dat er geen state verloren gaat als de web server herstart)
Output caching en gedeeltelijke pagina caching om stress op de server(s) te verminderen
Mogelijkheid om applicaties bij te draaien in een beveiligde "sandbox" om onheil te voorkomen (zeer handig voor Hosting Providers)
Per applicatie performance monitoren (makkelijker om problemen op te sporen)
Application_Error event dat gebruikt kan worden om administrators te waarschuwen bij applicatie fouten

<< vorige | ^ naar boven | overzicht | volgende >>