På applikationsservern
Om vi förutsätter att en sådan inte finns tillgänlig och det skulle vara för dyrt att köpa in?
Prestandatänk vid nyutveckling
31 svar · 808 visningar · startad av Brimba · sida 2 av 2
Frågan, av Brimba
Hej! Hur ser ni på att bygga objektorienterat eller inte bygga objektorienterat vid större projekt som kräver enorm prestanda? Har ni erfarenhet? Berätta gärna om hur det var i ert fall. Är det någon som har byggt ett system objektorienterat med sedan fått bygga om på grund av prestandaproblem?
Läs frågan i sin helhet →Eller cacha i en fil eller i databasen. Kolla lite på MS Caching application blocks
Eller tumma på prestandan ;)
Brimba skrev:
<<snip>>
Samt då att ni i stort sett inte kan cacha någonting eftersom varje sida anropas med användarspecifika parametrar och resultatet till alla användarna skiljer sig alltså.Har ni erfarenhet av detta eller gissar ni?
Hjälpte till med en site för bra längesen som skulle klara så mycket som möjligt, dock inte i asp eller asp.net utan i php..
Vi började med att göra lite tester och såg då att OO inte var att användbart.
Men eftersom vi ville ha så hög prestanda som möjligt så byggde vi en cache som cachade hela sidor beroende på parameters, vilket innebar att vi kunde ha samma sida ett antal gånger i databasen, beroende på vad som skickades in. Ändrades någon parameter så dumpades sidan från cachen i databasen och lästes in nästa gång någon tittade på den. Tror det var så vi gjorde.. Lösningen blev inte speciellt komplicerad och ökade prestandan rejält. På varje sida var där väldigt många databas anrop och en del XML-rpc anrop till ett annat system.
Vi började med att göra lite tester och såg då att OO inte var att användbart.
Med tanke på att php inte är OO (ännu) så förstår jag det ;)
Men att programmera en miljö och ett språk som är OO och sen inte använda det är helknasigt! Har man byggt en större site och vill åstadkomma återanvändning, skalbarhet och god struktur är OO givet så länge miljön stödjer detta!
Jag tar för givet att vi talar om lite större applikationer nu...
Jon skrev:
Vi började med att göra lite tester och såg då att OO inte var att användbart.
Med tanke på att php inte är OO (ännu) så förstår jag det ;)
Men att programmera en miljö och ett språk som är OO och sen inte använda det är helknasigt! Har man byggt en större site och vill åstadkomma återanvändning, skalbarhet och god struktur är OO givet så länge miljön stödjer detta!
Jag tar för givet att vi talar om lite större applikationer nu...
Helt rätt..
Vi hade väldigt långa och intensiva diskussioner om detta. De slutade med att vi gjorde lite prestandatester där icke OOP vann, vilket var givet. Men på slutet av projektet så blev det mer och mer OO pga det blev för rörigt annars. Jag tycker att man gott kan satsa på att bygga OOP och skulle det uppstå prestandaproblem så kan man se om man kan bygga runt detta. En fördel med OO är just att man får ett mer flexibelt system som är mindre känsligt för förändringar och därför (kanske) blir lättare att tweak när problemen uppstår.
Om man är ute efter rå prestanda och inget annat så binder man en datareader till en repeater i sin codebehind data.
Det är absolut optimalt ur prestanda, och skulle det vara så att man kan använda sig av en cache, så cachar man inte datan, utan använder sig av funktioner i IIS6 som cachar HTMLresultatet, vilket iprincip ger dig en statisksida som redan finns i minnet, mycket snabbare än så lär du aldrig få tag i datan.
Tyvärr så försvinner underhålls och återanvändningsvänlighet all värdens väg när man gör så. Men är du ut efter prestand så.
Dock så börjar vi kom in på andra aspekter här så fall. Så som begränsningar i hårdvaran, som antal processorer, minne samt bland det viktigaste för en webserver, IO-enheter, du måste ha grymt snabba IO-enheter om du inte vill att ditt nätverkskort/hårddisk skall bli din flaskhals, när dina 8 processorer med 16 GB RAM börjar jobba. Helt plötsligt så blir kommunikationen mellan webservern och databasen din stora flaskhals, kanske skall flytta in databasen i samma server så slipper du ut på nätverket och hämta data.
OO är ett programmerings filosofi för att skapa återanvändings och underhållsvänlig kod, inte för ren prestanda. Dock så får man inga större prestanda förluster att programmera OO jmf med proceduellt, dock är de andra vinsterna så mycket större.
- M
Jag tror helt klart att det är skillnad på "sajter och sajter". En sida som tex. MSN som har ofantligt många träffar per dag, men har mycket statisk information, där cachning och "utarbetad" OO lämpar sig mycket bra....
...sen finns det andra sajter. Tex. Lunarstorm, som jag hört generar lika mycket bandbredd per dag som hela Varberg tillsammans...Med gissningsvis ett 40-tal servrar, så är prestandan allt. Där spelar det ingen roll hur pass bra det än är för dynamik och underhåll att bygga fler-skiktade OO-klasser, utan det gäller att snabbt som blixten hämta och visa uppp data. Cachning på en sån sajt kan också bara användas på ett fåtal ställen, då nästan all information som visas upp är beroende av användarens egna val och kriterier. Visst kan man cacha all data i minnet som det sagts här tidigare, men om det nu inte är läge att ha applikations-servrar för cachning, var ska man lägga den då?
Ja, det var bara min synvinkel på diskussionen :)
Jag tycker att det känns som om det finns en utbredd och enligt mig helt ogrundad mening att OO alltid skulle resultera i långsamare kod. Har aldrig någonsin sett någon undersökning som visar att detta ALLTID är fallet. Betänk att allt är objekt i rena OO språk, dvs värdetyper, Responseobjekt, Pageobject osv. OO har IMHO mer att göra hur dessa struktureras upp, används och relateras till andra/egna objekt.
Ta en titt på utvecklingen av PHP5 så ser ni att program som är OO till och med har visat sig bli snabbare än sina proceduriella motsvarigheter.
Jag är inte en omöjlig person men jag tänker inte köpa denna argumentation bara för att "folk" säger det :)
Sen tycker jag inte att man ska glömma att asp.net är så ofantligt mycket snabbare än asp hur man än gör. Och den senaste standardwebservern är dubbelt så snabb som den för 3 år sedan. Detta ger ju en prestandaökning på massa % redan från start. (vågar inte gissa hur många, men många är det, förmodligen 3-siffrigt)
Jag tycker att det känns som om det finns en utbredd och enligt mig helt ogrundad mening att OO alltid skulle resultera i långsamare kod.
I just detta fall så menar trådskaparen att det blir långsammare att mappa om datan i en databas till objekt och collection, och det stämmer att det blir långsammare än att bara binda datan till en repeater direkt från datareadern.
Sedan så blir OO lite långsammare med tanke på att du oftas måste göra fler metodanrop, instanser av klasser, typeconverteraingar från objekt till "strong object". Det är isig ingen stor prestandaförsämring, om man lär knappast märka det, och det finns bra mycket viktigare saker att lägga krutet på, men men men, det tar faktiskt några processorcyklar att genomföra och därmed så blir det en prestandaförsämring, även om man aldrig kommer att märka det eftersom andra faktorer påverkar så ofantligt mycket mer.
Jag kan göra en ASP lösning på en gammla P31GZ som är snabbare än en ASP.NET lösning på en P4 3GHZ, de gör samma sak, men man kodare det olika bra. Så om man inte skriver sin kod efter konstens alla regler så har man ingen nytta av sin hårdvara eller för kompilerade filer.
- Magnus
Kan detta vara något läsvärt?
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dndotnet/html/autousa2.asp
( under Performance)
Jag kan göra en ASP lösning på en gammla P31GZ som är snabbare än en ASP.NET lösning på en P4 3GHZ, de gör samma sak, men man kodare det olika bra. Så om man inte skriver sin kod efter konstens alla regler så har man ingen nytta av sin hårdvara eller för kompilerade filer.
Håller med fullständigt! Poängen var mest att du kan göra .net lösningen väldigt mycket snabbare än asp lösningen om du gör rätt :)