[ASP] pagina's zonder ASP-code trager dan HTML pagina's?*

[Verwijderd]

Op onze 2 webservers worden zo`n 60-tal site`s gehost. Alle site zijn opgebouwd met een mengelmoesje van HTML en ASP bestanden. Ik wil dit een beetje recht gaan trekken, want het komt nu wel heel vaak voor dat ik (na gelang het doel van de pagina) een HTML pagina moet wijziging in een ASP pagina. Gevolg: partners welke een link hebben opgenomen naar de HTML pagina moeten deze link ook gaan veranderen naar een ASP extensie.

Het lijkt mij helemaal geen bezwaar om bij het maken van een nieuwe site deze volledig op te bouwen uit alleen maar ASP bestanden (ook al bevatten sommige ASP bestanden helemaal geen ASP code).

Vraag 1: Is de nieuw gemaakte site (die volledig uit ASP bestanden bestaat) trager dan het eerder genoemde mengelmoesje van ASP en HTML bestanden?

Vraag 2: Indien ik alle 60 websites ombouw naar ASP zou dan misschien de performance / snelheid van de webserver achteruit gaan?

Vraag 3: Als een ASP pagina ASP code bevat, dan wordt deze (als ik het goed heb) door een parcer gehaald op de webserver. Gebeurd dat ook als de ASP pagina geen ASP code bevat?

Wat denken jullie?

Groeten,
Pascal.

.modbreak: open voortaan 1 topic, crossposts zijn niet toegestaan

[ Voor 5% gewijzigd door .oisyn op 13-11-2003 13:49 ]

[Verwijderd]

Alleen ASP code zelf wordt door de DLL gehaald lijkt me. Maar als je server sneller is dan een 266 mHz computer dan zou ik zeggen: omgooien die boel. Die performance die je verliest zal niet eens zichtbaar zijn, als er al een verlies is..

Gemak dient de mens.. als je je een dag per maand scheelt heb je de overhead kosten er zo weer uit

[LauPro]

Afaik wordt een .asp pagina (mits ingesteld) altijd door de asp-parser gehaald. Wanneer er scriptblokken in zitten (bijv. VBScript) dan wordt deze plugin geladen en uitgevoerd. Ik denk echter dat het performanceverlies minimaal is.

[Verwijderd]

Ja klopt Pelle, sorry, ik zag te laat dat ik mijn vraag hier beter had kunnen stellen...

[P_de_B]

1. Nee

2. Nee

3. Nee

Sinds de komst van IIS5 zit er geen perfomanceverschil in het switchen tussen HTML en asp, of het gebruiken van pure html pagina's met .asp extensie.

[Verwijderd]

Meten is weten, bij visual studio zit een stress test tooltje ( bij de .Net variant in elk geval ).

En in het geval van Asp.Net maakt het in mijn ervaring zeker uit.

[Verwijderd]

1: je bedoeld de hele tijd response.write gebruiken? nee makt niet veel uit
2: ligt aan je server, maar je krijgt wel iets van een performance verlies..
3: ja, extensie triggert de asp.dll

ik zou zeggen: geen asp in je pagina? .html wel asp?: .asp
en volgens sommige (vind het een beetje onzin) zo min mogelijk switchen tussen html code en asp code (dus: response.write("blaat") in plaats van %> blaat <%


sim-pel

[Verwijderd]

Bedankt voor jullie (snelle) antwoorden! Ik denk dat ik nu echt serieus ga overwegen alles te standaardiseren en voortaan door de hele site ASP te gebruiken.

Als er nog meer meningen zijn dan hoor ik die uiteraard graag...

Groeten,
Pascal.

[ Voor 18% gewijzigd door Verwijderd op 13-11-2003 14:06 ]

[PanMan]

Het zal trager zijn: De webserver gooit een HTML pagina direct richting client, terwijl hij een ASP pagina richting ASP parser gooit. Dei ASP parser bepaalt dan zelf of er ASP code in zit, of niet.
Ik ben het even gaan testen. Aangezien ik geen servers gebruik die ASP ondersteunen, maar wel PHP, en dit het zelfde principe is, heb ik het daarmee getest.
Ik heb eerst een pagina gemaakt, die als .PHP en als .HTML opgeslagen, en die vervolgens 1000 keer opgehaald met Apache Benchmark:
/opt/apache/bin/ab -n 1000 http://panman.nl/temp/temp/test.htm
Time taken for tests: 1.825 seconds
Vervolgens heb ik de PHP pagina getest (die een kopie is van de HTML)
Time taken for tests: 6.386 seconds
(was overigens nog best een gezeik, had hem eerst als HTML opgeslagen, bleek
dat HTML op deze server ook door PHP heen wordt gehaald )

Maar, het resultaat is duidelijk: Hoewel het nogsteeds bloedje snel gaat (Requests per second: 163.64 [#/sec] met PHP), is het toch bijna 3x zo traag als pure HTML. En, dan heb ik nog niet naar serverload gekeken, die zal ook hoger zijn bij de PHP requests.
Dus, wellicht heeft het wel degelijk invloed op de performance van je server, als je alles als ASP laat parsen.
* PanMan is blij met z'n uitgebreide reply .

Nog een toevoeging:
Ik heb wat PHP code toegevoegd aan een pagina, test3.php
Zodat hij de unix timestamp echo't, hele lichte code dus.
En dat blijkt niet te schelen met GEEN PHP code:
Time taken for tests: 6.081 seconds (Is zelfs minder, maar dat zal wel toeval zijn )
PHP dus wel een beetje of geen code laten uitvoeren scheelt vrijwel niet in tijd. (als het lichte code is, natuurlijk).

Nog een toevoeging: Alle tests zijn uitgevoerd vanaf de server waar de site ook op staat: Netwerk-response tijden zijn hier dus uitgesloten.

[ Voor 20% gewijzigd door PanMan op 13-11-2003 14:44 ]

[j_du_pee]

Verwijderd schreef op 13 november 2003 @ 13:58:
Als er nog meer meningen zijn dan hoor ik die uiteraard graag...

ik heb ook nog een mening Ik ben het met alles wat hierboven wordt gezegd eens, maar:

Stel dat er op zo'n website een aantal HTML pagina's staan met lappen tekst van 2 MB (stel ) Bij het opvragen van de HTML pagina stuurt de browser van een bezoeker die de pagina al eens bezocht had mee, dat hij een versie van b.v. eergister in de cache heeft.
IIS kijkt vervolgens naar de pagina en bedenkt dat de gecachte versie niet meer is gewijzigd; stuurt een 302 Not Modified en gaat verder met waar hij zoal mee bezig is.

Bij je ASP pagina's wordt het anders. Om de dynamische content ook echt dynamisch te laten zijn geef je daar headers mee, die bepalen of er een nieuwe versie moet worden opgehaald, of dat de gecachte HTML output op de client ook door de beugel kan. Omdat je niet voor alle pagina's op alle sites uit wil gaan zoeken hoe lang deze expire tijd moet zijn, zet je die waarschijnlijk op altijd een nieuwe ophalen. Gevolg is dat de lappen tekst opnieuw worden opgehaald van de harde schijf en over het lijntje moeten worden gestuurd..

[ Voor 2% gewijzigd door j_du_pee op 13-11-2003 14:26 . Reden: taalverloedering ]

[P_de_B]

PanMan schreef op 13 november 2003 @ 14:19:
Het zal trager zijn: De webserver gooit een HTML pagina direct richting client, terwijl hij een ASP pagina richting ASP parser gooit. Dei ASP parser bepaalt dan zelf of er ASP code in zit, of niet.
Ik ben het even gaan testen. Aangezien ik geen servers gebruik die ASP ondersteunen, maar wel PHP, en dit het zelfde principe is, heb ik het daarmee getest.[knip]

Ik heb wel een server die asp ondersteunt en ik heb het ook even getest, 1000 keer een opgenomen sessie (met Microsoft application Test center) afgespeeld met .asp en met .html allebei in een tijd van 41 seconden.

De opname bestond puur uit het opvragen van de pagina.

Ik heb rechtstreeks van een MS medewerker gehoord dat het geen verschil maakt.

[ Voor 1% gewijzigd door P_de_B op 13-11-2003 14:58 . Reden: quote tags gefixt ]

[Eelke Spaak]

Waarschijnlijk zit er ook nog een verschil tussen het principe van ASP en PHP met betrekking tot uitvoeren/parsen van scripts. Met andere woorden: PanMans test is niet relevant voor het probleem van de TS.

[Verwijderd]

Hoi,

P_de_B
j_du_pee
PanMan

Super bedankt voor jullie (erg) uitgebreide uitzoekwerk! Hier kan ik iets mee! Ik denk dat we het hier gewoon eens moeten testen bij 1 complete site en dan goed monitoren of er performanceverlies is.

Allen hartstikke bedankt voor jullie reacties!

Groeten,
Pascal.