[Absona]

[mikk36]

Absona, ja kiirus puutub teemasse kuidas ?

[Absona]

[mikk36]

Absona, toimivust ei muuda ja aeglus on enamasti millegist muust põhjustatud, näiteks SQL'ist info pärimine jne.

[Absona]

[mikk36]

Absona, enamus ajast on lehed piisavalt lihtsad et lehe laadimise aeglaseimaks osaks on päringute edastamine serverile ja vastuse alla laadimine, töötlusaeg on lihtsalt niipalju lühem.
Jah sünteetilistes testides on ASP.NET kiirem, kuid need on ka testid, kus script jookseb mitmeid sekundeid, et läbi viia miljoneid tehteid.
Demagoogia ühesõnaga.

[Absona]

[mikk36]

Absona, kui palju muudab see siis veebilehe lugeja jaoks kui lehe genereerimise aeg on näiteks 0.0004 või 0.0002 sekundit ?
Lisandub siis veel 0.02 sekundit päringu saamtmiseks ja 0.05 lehe alla laadimiseks, kokku 0.0702 kuni 0.0704 sekundit, millele omakorda lisandub brauseri lehe renderdamise aeg.

[inzinz]

offtopic: Enamasti java veebilehed ja asp.net veebilehed on just need kõige räigemad ressursisööjad ja aeglusehunnikud üldse, kuna kasutatakse hunnikus dataprovidereid jms (hibernate, nhibernate) mis teevad üleliigselt tööd ja päringuid ning hoiavad liiga palju infot mälus. Promotakse kül et hea cluster support ja failover jne jne, aga väga lihtsalt annab kuskil ämbrisse astuda nii et tulemuseks on see, et iga 50 külastaja kohta on uut serverit vaja juurde kuna muidu ei vea välja Pluss PHP's annab ka väga efektiivselt teha cluster supporti, lihtsamalt kui keegi arvatagi oskab
Php jaoks on olemas template mootoritest smarty näiteks. Kui smartyga koos kasutada eacceleratorit (baitkoodi cachejat et kiirendada php laadimist) ning muidu normaalselt progeda, siis näiteks minu tehtud lehtedel on kõigil genereerimisaeg 0.01 sekundi kanti ja kui tegemist lihtsa sisulehega vms siis on genereerimise aeg isegi 0.005 sekundi kanti.

ontopic: Ei saa hästi aru, kas probleem tekkis kui IE8 peale panid masinale või on probleem ka IE7'ga juba ennem ? Või tekkis peale SP3 peale panemist ?
Kui tekkis peale seda kui IE8 olid peale proovinud, siis võis IE8 kuskile midagi teha mis nüüd ära rikub asju, sellisel juhul (kui pole veel teinud) soovitan IE8 maha lasta, mis peaks IE7 tagasi panema põhibrauseriks. Kui see ei aita siis ei oska muud soovitada peale browseri settingute ülevaatamise veelkord.
Kui tekkis lampi IE7'ga juba ennem, siis võib olla probleemiks hoopis ülikoolilehes.
Võid uurida ülikooli infosüsteemi adminnidelt, ehk on neil aimu mis valesti võib olla ja kas on sellega varemgi kokku puutunud.

[Absona]

[inzinz]

offtopic:
Absona ära solvu kohe ja lahmi niisama huupi, vahi www.whiteboardmeeting.com aadressil olevat proget, tehtud winformsi .NET rakendus sõbra ja minu poolt. Ei ütleks just et ma toorelt windowsi vastase mentaliteediga olen. Ma olen reaalselt töötanud ASP.NET arendajana (vabal ajal teen C#'s desktop progesid kui miskit vaja) ja ka Java veebilehe arendajana (ja teinud ka applete ning desktop rakendusi) ja ka PHP veebilehe arendajana.
Paluks mitte niisama lahmida kastidesse paigutamist kui ise tea mis reaalselt toimub ja ei oska erinevaid keeli programmeerimise seisukohast omadest kogemustest võrrelda

Ma tean väga hästi et asp.net'l on template süsteem olemas, samamoodi on php'l smarty väga kärme asjandus, samamoodi on javal jsp ja jsf süsteemid. Põhierinevus tuleb koodi mahust. Tavalise java veebirakenduse koodis exceptioni stacktrace on mingi 50-70 rida !! millest enamus on seal kuskil hibernate või template süsteemis. Samasse kanti on ka ASP.NET'l need stacktraced kui viewstate järgi komponendipuud ülesse ehitades mingi error tuleb. Ma olen PHP's väga kiirelt suht keerukaid lehti teinud, mille genereerimise aeg on väga kiire ja kus kõige suurem stacktrace errori tekkimisel on mingi 10 rida, keskmiselt aga 5 rea kanti. Kui skriptimise keelega saab hakkama vähema keerukusega kui masinkompileeritud koodis ning sama kiiruseg, siis on edu skriptimise keelel kuna vähem keerukust = vähem vigasid, pluss see suurem keerukus nullib ära igasuguse masinkompileeritud keele kiiruse võidu skriptimise keele ees (mida muidu väga suurelt promotakse igal pool). Ma tean väga hästi et kui vaja posu numbreid liita ja toorelt matemaatilisi tehteid teha suurel hulgal, siis java ja C# on kõvasti paremad kui php, veel etem oleks c ja veel etem assembler . Tööriist tuleb valida vastavalt olukorrale.
Olen komistanud java veebilehti tehes Hibernate bugide otsa pluss Seam süsteemi bugide otsa mida kumbagi lihtsalt ise parandada ei saa eriti kuna need on ehituselt suured ja keerukad. Samamoodi koperdasin ASP.NET arendajana mitmete asp.net jamade otsa kus mingil erijuhul järsku loogika ei töötanud ja tuli workarounde leiutada. Ka php's olen smarty jamade otsa sattunud (ei luba templates teha koodi stiilis $obj->Func()->Func2() mis tegelikult on korrektne kuid smarty ei saanud aru sellest)

Nüüd peaks ootama et teema algataja ragner ka midagi ontopicut siia ütleks

[Renka]

[Renka]

Splittisin vaidluse Võistlustandrisse.

[inzinz]

Noh, Absona antud link selgitab iseennast, seal on kirjas et kui vaja portability't et igal pool töötaks, siis php on kõige etem. Pluss kommentaarid valdavalt suunaga et php on parem kui asp ning ka parem kui asp.net.
Ei saa hästi aru kus otsast see pidi tõestama asp.net tohutut eelist.

Jube tihti kommenteeritakse niisama ise süvenemata. Absona üritab seletada et php'd ainult html ja php segamini tehaksegi, kui aga tõin näite template süsteemist korralikust, siis oli vastuseks ainult et asp.net omab ka template süsteemi, et pole see nii jube eelis midagi php'l
Asi ongi selles et on template süsteemid kõigil, lihtsalt asp.net ja java omad on kordades keerukamad ja selle keerukuse poolest ei ütle küll et ka sama kordades bugivabamad.

[Absona]

[inzinz]

Sa ei saa poindile pihta ikka üldse.
Ma ei räägi keerukusest koodis mida sina pead tegema vaid alusraamistiku keerukusest ja sealt tulenevast ajakaost ja bugidest (näiteks hibernate java jaoks, nhibernate .net jaoks). Kõik on ilus ja tore kuni koperdad bugi otsa mida ise parandada kohe ei oska ilma midagi mujal lõhkumata, kuna kood kus viga on, on suur ja lai ning tõenäosus parandamise asemel lõhkumiseks on suur.

Seesama alusraamistike suur koodimaht (kümned ja kümned read stacktraces) on seesama mis sööb palju ressurssi ära (aega peamiselt, kohati ka mälu) ning viib veebilehe kuvamise kiiruse poolest asp.net ja php lehed samale tasemele.
Ma ei eita et asp.net on hea ja mugav arendamiseks, saab visuaalselt forme ja lehte kokku ehitada, css completition ja javascript completition olemas, samas c# koodis progeda lehe põhiloogikat. Lisaks on ajaxi värk olemas ametlik, mis võimaldab updatepanelitega tuua asp.net lehele kiirelt ja mugavalt ajaxiga lehe osade uuendamise (asja mida php's ei anna nii lihtsalt teha et lohistad miski asja kusagile ja ongi olemas, see tuleneb component tree ehk viewstate kasutamisest asp.net's mida php's ei tea et keegi üritaks edukalt järgi teha).

Ainus asi millega java ja asp.net suurelt uhkeldavad on clustering/scaling/failover ehk siis mitme serveri paralleelselt kasutamine... aga võin öelda et sama asja saab ka php'ga teha ja mitte sugugi halvemini ja oluliselt rohkem vaeva nõudvamalt

A küsimusena niipalju, Absona, et kui palju kasutajaid sul tavaliselt asp.net peal jooksvad keerukamad lehed välja jooksutavad ? Ja palju on keskmine lehe genereerimise aeg (mitte arvestades juurde html koodi browserisse jõudmist) ?

Edit:
Vaikus....