Code hergebruiken met include (of niet?)

Door Michiel van Otegem
1 maart 2001

Include bestanden hebben veel voordelen. Ze geven ons de mogelijkheid om code op verschillende manieren te hergebruiken. We kunnen HTML of ASP code in een bestand zetten en dit bestand invoegen in een pagina op de plek waar we de HTML willen weergeven of de ASP code willen uitvoeren. Verder kunnen in zo'n bestand functies en klassen plaatsen en deze aanroepen vanuit de pagina die dit bestand heeft ingevoegd. Hoewel deze manier van werken voordelen heeft, zitten er ook enkele nadelen aan. We moeten wat dieper in ASP duiken om te zien welke nadelen er zijn...

ASP onder de kap

Om de prestatie te verbeteren, compileert ASP opgevraagde scripts en slaat deze op in een geheugen cache. De volgende keer dat een script uitgevoerd moet worden, gebeurt dit vanuit de cache, in plaats van dat het script wordt herladen en gecompileerd. De prestaties van ASP wordt daar enorm veel door verbeterd, hetgeen je kan zien als we meten hoe lang het duurt om een script uit te voeren (zie Hoe snel is mijn code?). De tweede keer dat een script wordt opgeroepen, is de extra tijd voor compilatie er niet en wordt het script dus veel sneller uitgevoerd.

De ASP cache is niet bodemloos. IIS 5.0 cached standaard 250 scripts en verwijdert een script om ruimte te maken voor het 251e script. Je kunt deze instelling wijzigen onder Script File Cache in Home directory - Configuration - Process Options in de WWW Service Master properties (MMC). IIS 4.0 cached standaard een ongelimiteerd aantal scripts, maar dat zou uiteindelijk de server ernstig vertragen, omdat het fysieke RAM geheugen z'n grenzen heeft. Dit is dan ook waar problemen met include bestanden naar voren komen...

Bestanden worden ingevoegd voor er ASP code wordt uitgevoerd. Dit betekent dat bestanden altijd worden ingevoegd, of ze nu nodig zijn of niet. Bovendien cached ASP het totale script, inclusief de ingevoegde code. Een andere pagina die dezelfde code uit een include bestand gebruikt, heeft hier geen voordeel aan, voor die pagina moet het include bestand afzonderlijk worden ingevoegd en gecompileerd. Het gevolg is dat er voor elk script dat het include bestand gebruikt een volledige kopie van dat bestand in de cache staat. Dit geldt ook voor bestanden die meer dan één keer zijn ingevoegd.

Dus... wat doe ik eraan?

Het is duidelijk dat grote include bestanden met veel code die zelden wordt uitgevoerd vermeden moeten worden. Verder moet je voorkomen dat er geneste include bestanden zijn. In essentie moet je dus gewoon goed weten wat er gebeurt als je iets doet.

Alternatief 1: Server.Execute
In ASP 3.0 (Windows 2000/IIS 5.0) kun je gebruik maken van de functie Server.Execute. Deze functie voert het aangevraagde bestand uit op het punt waar de functie gebruikt wordt. Alle intrinsieke ASP objecten (Request, Response, etc.) zijn beschikbaar in het aangeroepen bestand. Wanneer dit bestand klaar is, wordt de controle teruggegeven aan het script dat het bestand opriep. Het voordeel van deze methode is dat een bestand met deze methode slechts één keer gecompileerd en gecached hoeft te worden. Als andere pagina's dit script aanroepen, wordt de gecachede versie gebruikt.

Een nadeel van Server.Execute is dat het aangeroepen script op zichzelf wordt gecached. Als de server (gezet is op) een beperkt aantal cache plaatsen, zou dit wel eens waardevolle cacheruimte verbruiken, omdat er minder scripts in de cache kunnen. Net als met includes, moet je dit dus voorzcihtig gebruiken. In sommige gevallen zijn includes en Server.Execute uitwisselbaar. Je kunt dan beide gevallen testen onder veel hits en kijken welke in dat geval beter werkt.

Een ander nadeel van de Server.Execute methode is dat we geen functies kunnen aanroepen in de code. Alles wordt gewoon uitgevoerd. We kunnen hier alleen omheen door het Session object als een soort stack te gebruiken en er de gewenste functie en de parameters in op te slaan. Het bestand dat wordt uitgevoerd kan deze waarden uitlezen en gebruiken om een bepaalde functie aan te roepen. Op dezelfde manier kunnen we waardes retourneren.

Alternatief 2: Componenten maken
Als je echt serieus code wil hergebruiken, dan kun je het beste componenten maken. Net als met includes kunnen we functies van een component aanroepen die bepaalde taken uitvoeren. Het resultaat kan direct in de ASP pagina geschreven worden, of als een waarde geretourneerd worden.

Componenten zijn gecompileerd en zijn daardoor sneller dan script. Er is wel enige extra tijd nodig om een component te instantiëren, dus is deze aanpak niet geschikt voor kleine stukjes code. Daar staat tegenover dat problemen met include bestanden pas ontstaan als we grote lappen code gebruiken.

Conclusie

Wat hierboven besproken is, is slechts een leidraad om je te helpen beslissen wat het best is in bepaalde gevallen. Als je een server hebt met 256 Mb geheugen (of meer), zal je niet zo snel problemen hebben. Daar komt bij dat elk geval anders is. Als je de mogelijkheid hebt, kun je het best de verschillende scenario's testen.