Hej Anders
Først vil jeg sige at jeg har taget fat i netop de artikler i andre i
diskussionen henviser til for at illustrere hvad jeg mener, og for at nye
tilkommere også kan følge med.
"Anders Holbøll" <dev-null-20010820@serveren.dk> skrev i en meddelelse
news:3B8A2B69.1853337E@serveren.dk...
> Allan Ebdrup wrote:
> > Anders Holbøll skrev:
> > > Der blev kun simuleret en enkelt klient (et hit af gangen),
> > > uden ventetid i mellem hits og hver test kørte i 1 minut.
> >
> > Det er ikke et særligt realistisk brugsscenarie, een bruger der
> > henter samme side tusindvis af gange på kort tid ? Hvorfor ikke
> > flere brugere ?
>
> Jeg vurderede, at det var mindre væsenligt i denne test, hvor mit mål
> var at måle den "rå performance" af funktions kald, parser compiler.
> Desuden var prosessoren som angivet, allerede max'et ud med en klient.
Ja, men hvem er interreseret i performance på en webserver, det er altid
scalability der er vigtigst, og da de i dine tests sikkert går hånd i hånd
ville du sikkert finde det samme resultat i dine tests. Man kan dog blive
overrasket over hvad der sker med performance når der kører mange ting
parallelt, og det interesandte er vel performance ved mange samtidige
brugere (ja det er lidt flueknepper agtigt, men jeg synes det er vigtigt
> > > Ud fra dette konkluderer jeg:
> > > - Det er ikke et specielt stort problem (rent performance
> > > mæssigt) at hoppe ind og ud af script-blokke (2b, 2c, 5)
> >
> > Korrekt, det er også hvad MS skriver, de fraråder at gøre det i
> > en for løkke, dvs. rigtigt mange gange. Derudover nævnes det at
> > problemet er værst når response.buffer ikke bliver brugt, og det
> > gør de fleste vel?
> > (<
http://msdn.microsoft.com/library/en-us/dnasp/html/asptips.asp>
> > - Tip 15: Batch Inline Script and Response.Write Statements)
>
> Bemærk, at der står "Det er *ikke* et specielt stort problem". Dette er
> modsat hvad microsoft skriver, på den side (som jeg også før har henvist
> til).
Det er nu ikke sådan jeg læser hvad MS skriver, som sagt er deres anbefaling
hovedsageligt for når response.buffer ikke er slået til (Hvilket de
anbefaler at gøre i tip Tip 14: Use Response Buffering, lige ovenover) og så
er det endda kun når man har loops de anbefaler at slå udskrift samme til et
response.write kald. Hvis de kun anbefaler denne optimering i så specielle
tilfælde læser jeg det somom det ikke er et problem for de fleste tilfælde.
> > > - Programørene der har lavet vb-script compileren har røget sig
> > > skæve inden de skrev den, da concatingeringen (der åbentlyst kun
> > > består af konstanter) ikke er optimeret væk. (4)
>
> Dette er naturligvis ikke blot bygget på test 4, men på en sammenligning
> af test 3 og 4.
>
> > VBScript bliver ikke compileret i ordets gængse betydning men
> > bliver fortolket af et fortolker program, derfor er det ret
> > begrænset hvor meget optimeringsanalyse det kan betale sig at
> > foretage på koden da det skal fortolkes real-time.
>
> Jeg har før hørt fra microsoft, at asp blev compilet først gang scriptet
> blev kørt og derefter blot eksekveret. At dette muligvis ikke er
> tilfældet syntes jeg er ganske uforsvareligt.
Igen, kompilet betyder bare at de henter alle include filerne samme til et
stort script og ligger det i buffer, der foregår ingen kompliering til
maskinkode eller lignende. Uforsvarligt er nok et stærkt ord at bruge, men
det er rigtigt at det kunne gøres meget bedre, det er bla. også derfor der
er så meget bedre performance med IIS 5, MS har gjort en del for at optimere
script fortolkeren. MS har dog i meget lang tid anbefalet at hvis du vil
have god scalability skal du anvende kompilerede COM/COM+ komponenter til
din forretningslogik.
Med .Net kompileres til bytecode som eksevekveres af et runtime, så kan der
optimeres meget mere, fejl kan fanges tidligere med et typestærkt sprog så
man slipper for en masse checks ved runtime, ligesom Java.
> > Teksten hos MS her:
> > <
http://support.microsoft.com/support/kb/articles/Q193/8/31.ASP>
> > Kan nemt opfattes misvisende. Ordet "compile" betyder "at samle
> > sammen", og det der bliver "samlet sammen" i ovenstående artikel,
> > er HTML'en der skal outputtes til brugeren - ikke verdens
> > heldigste ordvalg fra MS side.
>
> Der er jo en hårfin grændse imellem fortolkning og kompilering,
> teknikkerne er jo langt hen af vejen ens. (Det link har jeg også henvist
> til før i denne tråd og som Jesper påpegede så omhandler den en fejl i
> IIS4, der blev rettet af SP4 (dvs. for lang tid siden))
Det kommer meget an på hvad du mener med "ens", konceptuelt benyttes en del
fælles teknikker, men i praksis er der meget stor forskel mellem kompileret
kode og fortolket kode. At kalde grænsen mellem de to "hårfin" er nok en
overdrivelse.
> > > - Det er hurtigere at skrive "almindelig tekst" end at benytte
> > > Response.Write. Programmørene har muligvis også været fulde.
>
> Dette er bygget på en sammenligning af test 1b og 3.
>
> > Hvorfor det? Response.Write er et fortolket funktionskald der
> > skal pakke variable ned som argumenter, hoppe til et et andet
> > variabel scope køre noget kode og hoppe tilbage igen. Rå HTML
> > udenfor script blokkene skal bare kopieres til bufferen.
>
> Response.Write er et så alimindeligt/ofte brugt/basalt funktionskald, at
> det burde være optimeret (f.eks. ved "inlining").
Ja, men du skal stadig tage højde for at Response.Write kan have et input
der skal "evalueres" før det kan skrives, det er fortolket, mens rå HTML
udenfor script blokkene bare skal kopieres til bufferen, jeg kan ikke se
hvordan du nogensinde skulle kunne lave en Response.Write der er lige så
hurtig som rå HTML. Mht. at Response.Write i specialtilfælde kan skrive
"konstant" tekst ud så skyldes mangel på optimering i disse tilfælde igen at
VBScript er fortolket, det kan simpelthen ikke betale sig at analysere koden
for alle mulige optimeringer i et fortolket sprog.
MVH
Allan Ebdrup