mboost-dp1
Windcape (1) skrev:Umiddelbart kunne jeg nemt forestille mig at problemet er dårligt skrevet PHP kode ;-)
Jeg tror helt ærligt ikke at det er det der er problemet... Jeg mener, hvor mange brugere er det lige der er på facebook?
Men det er i orden hvis du kan kode facebook så det har et reduceret CPU forbrug, uden at skulle bruge diverse optimeringsværktøjer udover at renskrive koden.
Windcape (1) skrev:Umiddelbart kunne jeg nemt forestille mig at problemet er dårligt skrevet PHP kode ;-)
Er nok også én af grundene, men de har måske vurderet at tiden til at optimere compileren har været det værd ift. at performance-gennemteste deres kodebase.
Det er 50% hurtigere på det samme kode. PHP er baseret på en ret ueffektiv fortolker, så der er meget at vinde ved at forbedre det. Projektet compiler fra PHP kode til C++ kode og herefter køres den genererede C++ kode igennem en almindelig compiler med alt hvad det giver af optimeringer. Det er nok muligt at skære endnu mere af køretiden.Windcape (1) skrev:Umiddelbart kunne jeg nemt forestille mig at problemet er dårligt skrevet PHP kode ;-)
Aha så fik jeg da svar på hvorfor Facebook har opført sig mærklig i en længere periode og stadig gør...
Kan så sige at der er problemer i det for den vil ikke altid opdatere forsiden og andre gange vil updates ikke vise fra et par dage før altså 1 - 3 dage forsvinder men det kommer så tilbage :S
Kan så nu forstå hvorfor det har været sådan i den sidste tid :S
Kan så sige at der er problemer i det for den vil ikke altid opdatere forsiden og andre gange vil updates ikke vise fra et par dage før altså 1 - 3 dage forsvinder men det kommer så tilbage :S
Kan så nu forstå hvorfor det har været sådan i den sidste tid :S
#1
Med det ektreme load der er på Facebook har optimering af kode naturligvis høj prioritet. Og mit gæt er at de folk de har ansat til at lede udviklingen af deres system er meget dygtige.
Så mon ikke koden er temlig optimeret i forvejen? Tror du virkelig at Facebook er dumme nok til ikke at tænke på kode optimeringen før de tænker på den her løsning?
Generelt er det sgu ret utroligt hvor ofte en eller anden ubetydelig nørd på newz.dk tror han er klogere end lead udviklere hos firmaer som Facebook. Oven i købet uden at have nogen somhelst indblik i hvordan deres system fungerer internt.
Desuden er PHP et fortolket sprog som mathiass også nævner. Og i princippet er fortolkede sprog langsommere at afvikle end oversatte sprog. Hvilket bare gør din kommentar endnu mere tåbelig.
Med det ektreme load der er på Facebook har optimering af kode naturligvis høj prioritet. Og mit gæt er at de folk de har ansat til at lede udviklingen af deres system er meget dygtige.
Så mon ikke koden er temlig optimeret i forvejen? Tror du virkelig at Facebook er dumme nok til ikke at tænke på kode optimeringen før de tænker på den her løsning?
Generelt er det sgu ret utroligt hvor ofte en eller anden ubetydelig nørd på newz.dk tror han er klogere end lead udviklere hos firmaer som Facebook. Oven i købet uden at have nogen somhelst indblik i hvordan deres system fungerer internt.
Desuden er PHP et fortolket sprog som mathiass også nævner. Og i princippet er fortolkede sprog langsommere at afvikle end oversatte sprog. Hvilket bare gør din kommentar endnu mere tåbelig.
Jeg er da sådan set enig med ham i at det ikke er en compiler, da der oversættes fra et højniveausprog til et andet. Min opfattelse af en compiler er at den skal "et niveau ned".
Java compiles til en virtuel maskine, så en eller anden fortolkning skal der til, før hardwaren kan forstå koden.
Java compiles til en virtuel maskine, så en eller anden fortolkning skal der til, før hardwaren kan forstå koden.
mathiass (4) skrev:Det er 50% hurtigere på det samme kode. PHP er baseret på en ret ueffektiv fortolker, så der er meget at vinde ved at forbedre det.
PHP fortolkeren er nu ret hurtig, men et fortolket scriptsprog er selvfølgelig altid langsommere end præ-kompileret kode.
Facebooks løsning er interessant, men ikke særlig relevant for flertallet af hjemmesider. For de fleste vil det være mere interessant at optimere database-forespørgslerne og lave nogle gode cache-foranstaltninger.
anazonda (2) skrev:Jeg tror helt ærligt ikke at det er det der er problemet... Jeg mener, hvor mange brugere er det lige der er på facebook?
Onde Pik (8) skrev:Med det ektreme load der er på Facebook har optimering af kode naturligvis høj prioritet. Og mit gæt er at de folk de har ansat til at lede udviklingen af deres system er meget dygtige.
Ja for det var jo tilfældet med myspace :P
Ja, faktisk.Onde Pik (8) skrev:Så mon ikke koden er temlig optimeret i forvejen? Tror du virkelig at Facebook er dumme nok til ikke at tænke på kode optimeringen før de tænker på den her løsning?
Du kan jo f.eks. prøve at studere koden til f.eks. MediaWiki som blandt andet har været codebase for wikipedia.
Det er volsomt typisk at PHP løsninger bliver lavet uden overordnet arkitektur, eller fokus på performance, og så først senere når projektet er for stort til at du kan kode det om, bliver optimeret ved hjælp af f.eks. opcode cache, eller løsninger som denne her.
Java compiles til et simplere sprog kaldet Java bytecode som compiles (JIT) videre til native kode ved kørsel. Der findes også en fortolker i JVM'en med som sådan at kaldet Java fortolket er meget misvisende hvis det ikke er direkte forkert.Dan (9) skrev:Jeg er da sådan set enig med ham i at det ikke er en compiler, da der oversættes fra et højniveausprog til et andet. Min opfattelse af en compiler er at den skal "et niveau ned".[quote]Ok, den sædvanlige definition er at en compiler oversætter fra et source sprog til et target sprog (uden at lægge nogen restriktioner på hvad source og target er). At oversætte til Eksempelvis et subset af C for at bruge en gængs compiler til at lave binær kode er et trick som er ret udbredt.
[quote=Dan (9)]
Java compiles til en virtuel maskine, så en eller anden fortolkning skal der til, før hardwaren kan forstå koden.
Men den ubetydelige nørd har også mange års erfaring med udvikling af systemer i PHP.Onde Pik (8) skrev:Generelt er det sgu ret utroligt hvor ofte en eller anden ubetydelig nørd på newz.dk tror han er klogere end lead udviklere hos firmaer som Facebook.
Og den ubetydelige nørd sagde at han "kunne forestille sig".
Altså, det var en tanke. Måske skulle du lære at læse indlæg ordenligt. Du er også selv en ubetydelige nørd, og derfor vil du så aldrig forholde dig kritisk til noget som helst I guess?
Den er relevant fordi man i princippet kan skifte som PHP fortolker ud med denne compiler og opnår at ens PHP kode kører dobbelt så hurtigt uden at gøre noget som helst for det selv. Den væsentligste begrænsning er at eval ikke er understøttet, men det er der sådan set ingen grund til at man ikke skulle kunne understøtte. Facebook har nok bare ikke haft brug for det...jimmi (10) skrev:Facebooks løsning er interessant, men ikke særlig relevant for flertallet af hjemmesider. For de fleste vil det være mere interessant at optimere database-forespørgslerne og lave nogle gode cache-foranstaltninger.
Tjo, der er jo som sådan ingen grund til at sprog som PHP skal være langsomme. Der kan sagtens laves bedre implementationer af PHP, og at nogen rent faktisk arbejder seriøst på det må da netop gøre PHP mere interessant end det tidligere har været. Folk bruger PHP af andre grunde en hastighed. De bruger det fordi det er nemt at gå til og fordi det er let at skaffe programmører som kan finde ud af det. Performance problemerne er først aktuelle når sitet bliver stort.Windcape (17) skrev:Man kunne også vudere om det overhovedet er værd at bruge PHP som teknologi hvis man kan optimere hastigheden med 50%.
mathiass (16) skrev:Den er relevant fordi man i princippet kan skifte som PHP fortolker ud med denne compiler og opnår at ens PHP kode kører dobbelt så hurtigt uden at gøre noget som helst for det selv.
Bortset fra at man skal sidde og kompilere koden hver gang man ændrer det mindste, og iøvrigt skal have en dedikeret server med special opsætning for at køre det.
Hvilket altsammen er lidt overflødigt, hvis PHP-afviklingen ikke udgør nogen flaskehals.
#19 Du skal kompile ved hver ændring det er sandt, men det er jo kun én gang. Der er jo ingen der sidder og koder på en live side anyways.
Desuden kræver C++ ikke nogen speciel opsætning. Det er maskinkode efter det er blevet kompileret. PHP derimod kræver PHP fortolkeren.
Det er pænt svært at skrive webservices med C++. PHP er lavet til formålet, så det er meget mere anvendeligt til formålet. At man derefter kompilerer det om til en anden kodebase, er der jo ingen problemer i. C++ bliver jo også kompileret til assembly og derefter bytecode, fordi det er alt for bøvlet at skrive sådan noget selv.
Desuden kræver C++ ikke nogen speciel opsætning. Det er maskinkode efter det er blevet kompileret. PHP derimod kræver PHP fortolkeren.
Windcape (17) skrev:#16
Man kunne også vudere om det overhovedet er værd at bruge PHP som teknologi hvis man kan optimere hastigheden med 50%.
Det er pænt svært at skrive webservices med C++. PHP er lavet til formålet, så det er meget mere anvendeligt til formålet. At man derefter kompilerer det om til en anden kodebase, er der jo ingen problemer i. C++ bliver jo også kompileret til assembly og derefter bytecode, fordi det er alt for bøvlet at skrive sådan noget selv.
On-topic:
Spændende ellers. Det er jo blot endnu et redskab til brug i fremtidens web systemer som skal kunne skalerer i helt stor grad. Jeg er pænt sikker på at deres database systemer er optimeret i så høj grad som det nu er muligt. De skulle vist have to-tre centraler med grids af MySQL databaser kørende.
Så er det jo ganske naturligt at finde ud af hvor man ellers kan spare nogle ressourcer. Det er jo ikke kun tid der er tale om her. 50% færre ressourcer i brug er jo penge sparet på RAM og elektricitet. I en sådan skala, er det helt sikkert et seks cifret beløb de kan sparer årligt ved denne optimering.
(Almindelige dødelige kan selvfølgelig være fuldkommen ligeglade, da vores små sider kræver så lidt at det er fuldstændigt trivielt)
Spændende ellers. Det er jo blot endnu et redskab til brug i fremtidens web systemer som skal kunne skalerer i helt stor grad. Jeg er pænt sikker på at deres database systemer er optimeret i så høj grad som det nu er muligt. De skulle vist have to-tre centraler med grids af MySQL databaser kørende.
Så er det jo ganske naturligt at finde ud af hvor man ellers kan spare nogle ressourcer. Det er jo ikke kun tid der er tale om her. 50% færre ressourcer i brug er jo penge sparet på RAM og elektricitet. I en sådan skala, er det helt sikkert et seks cifret beløb de kan sparer årligt ved denne optimering.
(Almindelige dødelige kan selvfølgelig være fuldkommen ligeglade, da vores små sider kræver så lidt at det er fuldstændigt trivielt)
Websider, Ja. Webservices, nej.ipwn (20) skrev:PHP er lavet til formålet, så det er meget mere anvendeligt til formålet. At man derefter kompilerer det om til en anden kodebase, er der jo ingen problemer i.
PHP's biblioteker til f.eks. SOAP er virkelig elendige. Så pas på med valget af udtryk.
Derudover så behøver jeg vel ikke sige mere hvis de bruger MySQL. Det er ikke en database som synes at skalere til det formål.
ipwn (20) skrev:Du skal kompile ved hver ændring det er sandt, men det er jo kun én gang. Der er jo ingen der sidder og koder på en live side anyways.
Come on, det er 100 gange lettere at skrive et scriptet sprog, end at skulle kompilere hver gang man »skal teste om det virker«. Der er en grund til at script-sprog er populære.
ipwn (20) skrev:Desuden kræver C++ ikke nogen speciel opsætning. Det er maskinkode efter det er blevet kompileret.
Ingen servere tillader at du uden videre kan uploade noget random maskinkode og køre det. Det ville være lidt et sikkerhedsproblem.
ipwn (20) skrev:PHP derimod kræver PHP fortolkeren.
Det er ikke ligefremt svært at finde en udbyder der har PHP installeret.
...
Læs evt. mere her...
So, what does HipHop PHP mean for the CodeIgniter community? In short, absolutely nothing.
http://www.michaelwales.com/2010/02/what-does-hiph...
http://www.brandonsavage.net/hiphop-for-php-who-be...
http://php100.wordpress.com/2010/02/03/hiphop/
jimmi (23) skrev:Come on, det er 100 gange lettere at skrive et scriptet sprog, end at skulle kompilere hver gang man »skal teste om det virker«. Der er en grund til at script-sprog er populære.
eller også har man vold-rådden computer som man koder C# på... :-D
#25
JVM fortolker kode blokke indtil de har taget et givent stykke processor tid, derefter kompileres det, baseret på statistik fra kørslen, hvilket forklarer hvorfor Java er dårligt til små ting (koden bliver aldrig kompileret). Så det er lidt vildledende at sige at Java er fortolket. Det er forresten også vildledende at sige at PHP er fortolket, da der eksisterer adskillige compilere til det.
Ontopic:
Gad godt vide hvilken compiler de bruger? Hvis de sidder og futter rundt med en Visual Studio compiler, burde de kunne få nogle meget større forbedringer ved at skifte til GCC, ICC eller en anden respektabel compiler.
JVM fortolker kode blokke indtil de har taget et givent stykke processor tid, derefter kompileres det, baseret på statistik fra kørslen, hvilket forklarer hvorfor Java er dårligt til små ting (koden bliver aldrig kompileret). Så det er lidt vildledende at sige at Java er fortolket. Det er forresten også vildledende at sige at PHP er fortolket, da der eksisterer adskillige compilere til det.
Ontopic:
Gad godt vide hvilken compiler de bruger? Hvis de sidder og futter rundt med en Visual Studio compiler, burde de kunne få nogle meget større forbedringer ved at skifte til GCC, ICC eller en anden respektabel compiler.
Sådan noget kan man sagtens automatisere. Det er for eksempel automatiseret i JSP som først compiles til Java og dernæst til JVM bytecode. Alt det sker automatisk under opstart og når filen ændres. Det kunne man sagtens gøre her også.jimmi (19) skrev:Bortset fra at man skal sidde og kompilere koden hver gang man ændrer det mindste, og iøvrigt skal have en dedikeret server med special opsætning for at køre det.
C# er ikke fortolket på nøjagtig samme måde som Java ikke er det. Java skal kompileres manuelt. Bytecoden er i begge tilfælde JIT-kompileret med mindre det er hurtigere at fortolke.LupusGrey (25) skrev:Som også bliver fortolket, præcis ligesom Java gør
JSP er noget andet end Java og JSP er i bund og grund noget skrammel som ikke yder tilnærmelsesvist så godt som det burde.LupusGrey (25) skrev:Vi har endda lavet en test på vores arbejde hvor vi prøvede JSP op imod PHP og vi bemærkede at PHP faktisk var hurtigere så længe vi kørte på den lille skala som vi gjorde.
Dem implementation som folk sædvanligvis bruger er en fortolker.dummyddd (26) skrev:Det er forresten også vildledende at sige at PHP er fortolket, da der eksisterer adskillige compilere til det.
dummyddd (26) skrev:#25
Ontopic:
Gad godt vide hvilken compiler de bruger? Hvis de sidder og futter rundt med en Visual Studio compiler, burde de kunne få nogle meget større forbedringer ved at skifte til GCC, ICC eller en anden respektabel compiler.
De bruger g++ :) Det er jo bare en makefile og så ellers bare et enkelt kald. Alt er helt sikkert automatiseret, så deres programmører ikke skal andet end at smide deres PHP ind, og så ellers checke om alt kompilerede korrekt.
Windcape (22) skrev:Websider, Ja. Webservices, nej.
PHP's biblioteker til f.eks. SOAP er virkelig elendige. Så pas på med valget af udtryk.
Derudover så behøver jeg vel ikke sige mere hvis de bruger MySQL. Det er ikke en database som synes at skalere til det formål.
Ah ja du har ret. Websider så :)
Angående MySQL, er det altså ikke en decideret dårlig løsning. Andre så som Google og Wikipedia bruger det jo også. Så der er ikke rigtigt nogen tvivl om at det kan klare enorme systemer. (Flere)
Hvis de har specielle behov, kan de jo altid selv rette i MySQL's kildekode, og tilpasse det til deres specifikke server farm.
Wikipedia benytter i høj grad cache, end databaser.ipwn (31) skrev:Andre så som Google og Wikipedia bruger det jo også.
Og Google bruger ikke MySQL, det er en vandrehistorie.
MySQL er generelt en dårlig performance database. Til en løsning some facebook ville Oracle eller DB2 være mere passende. Måske PgSQL fordi at PHP har ikke har ordenlige bindings til Oracle/DB2.
Men det er desværre et typisk valg for en løsning man aldrig forventer vil skalere.
Den lader vi lige stå lidt.ipwn (31) skrev:Hvis de har specielle behov, kan de jo altid selv rette i MySQL's kildekode, og tilpasse det til deres specifikke server farm.
De få folk der har kompetancer til det er typisk ansat hos et firma som udvikler databaser. Nej, at MySQL er open source har minimal betydning for dens business value.
# Optimering af PHP:
OOP i PHP er langsomt, så man opnår den bedste performance ved at skrive kode der er nær unmaintainable.
Det siger vel lidt omkring valget af PHP som teknologi. Jeg synes helt klart at Python eller ASP.NET ville være et mere sikkert valg.
Rails afhænger 110% af om de har fixet deres skaleringsproblemer. Sidste jeg kiggede (2 år siden) skalerede rails endnu dårligere end PHP.
OOP i PHP er langsomt, så man opnår den bedste performance ved at skrive kode der er nær unmaintainable.
Det siger vel lidt omkring valget af PHP som teknologi. Jeg synes helt klart at Python eller ASP.NET ville være et mere sikkert valg.
Rails afhænger 110% af om de har fixet deres skaleringsproblemer. Sidste jeg kiggede (2 år siden) skalerede rails endnu dårligere end PHP.
jimmi (23) skrev:Come on, det er 100 gange lettere at skrive et scriptet sprog, end at skulle kompilere hver gang man »skal teste om det virker«. Der er en grund til at script-sprog er populære.
Det hører jeg tit. Jeg koder i mange ting, lige fra bash til Java, og jeg kan altså ikke se forskellen i praksis. Kod, gem, test. (Gem er fx. "CTRL-S" og test er fx. "ALT-TAB, F5".) Piece of cake.
Det er ved at være mange år siden at kompilering nødvendigvis betød ventetid.
jimmi (23) skrev:Ingen servere tillader at du uden videre kan uploade noget random maskinkode og køre det. Det ville være lidt et sikkerhedsproblem.
Selvfølgelig tillader de alle sammen det. Hvordan ville du ellers installere og opdatere fortolkeren?
Og selv hvis det ikke skulle passe, så tillader man det naturligvis hvis man har behov for det.
Windcape (32) skrev:Den lader vi lige stå lidt.ipwn (31) skrev:Hvis de har specielle behov, kan de jo altid selv rette i MySQL's kildekode, og tilpasse det til deres specifikke server farm.
De få folk der har kompetancer til det er typisk ansat hos et firma som udvikler databaser. Nej, at MySQL er open source har minimal betydning for dens business value.
Fandt lige dette her.
Åbenbart så har de jo netop ændret på MySQL således at den passer med deres arkitektur. Kilden er dog gammel, men så vidt jeg ved bruger de stadig MySQL.
Not really, hotswap af kode i f.eks. GWT blev først implementeret i slutningen af 2009.myplacedk (34) skrev:Det er ved at være mange år siden at kompilering nødvendigvis betød ventetid.
Men nu er Java også storsynderen når det kommer til langsom udvikling pga. kompilering. Afhænging af hvilken teknologi du vælger kan det nemt tage evigheder.
#37
Java (og for den sags skyld også .NET) er noget af det som builder hurtigst.
Store C/C++ projekter med lidt gavmild brug af include filer kan tage lang tid at builde.
Jeg kan f.eks. godt huske den upgrade som reducerede total build af et bestemt system fra 24 til 8 timer.
Den slags kan mærkes.
Java (og for den sags skyld også .NET) er noget af det som builder hurtigst.
Store C/C++ projekter med lidt gavmild brug af include filer kan tage lang tid at builde.
Jeg kan f.eks. godt huske den upgrade som reducerede total build af et bestemt system fra 24 til 8 timer.
Den slags kan mærkes.
#38
Det er nok mere et spørgsmål om deployment. Jeg synes at ASP.NET+IIS , eller Apache+PHP/Python/Rails har en stor fordel i forhold til JEE og tunge applikationservere når det handler om udviklingshastighed.
Jeg mangler ihvertfald tålmodighed til at klare de 5-10 sekunder længere tid JEE kan være om at deploy og opdatere (hvis der ikke er cache bugs som f.eks. i defualt Tomcat).
Og for specielt PHP udviklere vil det føles utrolig langsomt at skulle arbejde med JEE.
Det er nok mere et spørgsmål om deployment. Jeg synes at ASP.NET+IIS , eller Apache+PHP/Python/Rails har en stor fordel i forhold til JEE og tunge applikationservere når det handler om udviklingshastighed.
Jeg mangler ihvertfald tålmodighed til at klare de 5-10 sekunder længere tid JEE kan være om at deploy og opdatere (hvis der ikke er cache bugs som f.eks. i defualt Tomcat).
Og for specielt PHP udviklere vil det føles utrolig langsomt at skulle arbejde med JEE.
Windcape (37) skrev:Not really
Du kan nævne en milliard langsomme teknologier, uden det modargumenterer mit udsagn.
Og bash du bare Java, men gør det lige for dig selv. Det er lige præcist Java, som jeg ikke har ventet på i årevis, mens jeg sidder i min udvikl/test-cyklus.
#39
Af hensyn til dem som ikke har fulgt med: Jeg har fortalt dig MANGE gange, at man kan lave J2EE-udvikling uden at sidde og vente. Jeg skal altså være hurtig til at trykke CTRL-S, ALT-TAB og F5, for at nå den inden den er færdig med at compile.
Troll.
#42
Modsat til myplacedk har jeg faktisk arbejdet med de teknologier jeg beskriver (i længere perioder end 2 timers hobbyarbejde), og giver dem kritik ud fra mine personlige erfaringer.
myplacedk modsat, er typen som ikke vil arbejde med C# fordi han synes Microsoft er onde.
Jeg tvivler på han ville lægge mærke til om det er 5 eller 20 sekunder for at deploy noget kode. Jeg har mødt massere af den slags mennesker.
Forskellen er bare at han bliver personlig fornærmet hvis man ikke er enig med ham.
Modsat til myplacedk har jeg faktisk arbejdet med de teknologier jeg beskriver (i længere perioder end 2 timers hobbyarbejde), og giver dem kritik ud fra mine personlige erfaringer.
myplacedk modsat, er typen som ikke vil arbejde med C# fordi han synes Microsoft er onde.
Jeg tvivler på han ville lægge mærke til om det er 5 eller 20 sekunder for at deploy noget kode. Jeg har mødt massere af den slags mennesker.
Forskellen er bare at han bliver personlig fornærmet hvis man ikke er enig med ham.
Windcape (43) skrev:Modsat til myplacedk har jeg faktisk arbejdet med de teknologier jeg beskriver
Den er jeg lige nødt til at reagere på, du snakker jo som om du ved noget om det.
Jeg udtaler mig ud fra erfaringer her. Jeg lever af at arbejde med J2EE. Jeg lever af at rådgive folk, som lever af det. Jeg kender godt de problemer du snakker om, jeg lider bare ikke under dem. Jeg prøver at fortælle dig, at det er et problemer der kan løses, hvilket er bevist af at jeg ikke har dem.
Resten du siger er også noget pjat.
Ja, det er jeg godt klar over!myplacedk (44) skrev:Jeg lever af at arbejde med J2EE.
Men hvad jeg siger at du ikke har nok erfaring til at kunne sammenligne det med de andre teknologier, og derfor skulle lade være med at brokke sig over at os som HAR arbejdet i årevis med .NET/PHP/etc. giver kritik af J2EE.
Windcape (45) skrev:Men hvad jeg siger at du ikke har nok erfaring til at kunne sammenligne det med de andre teknologier,
Og hvis jeg så fortæller noget mere om mine kompetencer, retter du det så igen til "det er jeg godt klar over"?
Jeg stopper her for denne gang, uanset hvad du kommer med af løgne og lort.
anazonda (2) skrev:Jeg tror helt ærligt ikke at det er det der er problemet... Jeg mener, hvor mange brugere er det lige der er på facebook?
Men det er i orden hvis du kan kode facebook så det har et reduceret CPU forbrug, uden at skulle bruge diverse optimeringsværktøjer udover at renskrive koden.
Der er rigtigt mange brugere på FaceBook, men det er ikke umiddelbart indlysende at problemet ligger i PHP eksekveringen.
Normalt regner man med at fortolkningsoverheadet for P'erne ikke er signifikant for en wep app.
Men FaceBook har forhåbentligt målt på performance og konstateret at de har en flaskehals i PHP eksekveringen.
Måske bruger de mere PEAR og mindre PECL end mange andre web sites.
Måske bruger de PHP, hvor de burde bruget noget andet, men har så valgt at fortsætte med PHP men bruge denne model, fordi det er nemmere med kun et sprog.
mathiass (4) skrev:Det er 50% hurtigere på det samme kode. PHP er baseret på en ret ueffektiv fortolker, så der er meget at vinde ved at forbedre det. Projektet compiler fra PHP kode til C++ kode og herefter køres den genererede C++ kode igennem en almindelig compiler med alt hvad det giver af optimeringer. Det er nok muligt at skære endnu mere af køretiden.
Nu synes jeg at de 50% er an af de mere mystiske detaljer.
Det er absolut ikke normalt at 50% af CPU tiden bruges på at fortolke PHP i en web app.
Windcape (13) skrev:Det er volsomt typisk at PHP løsninger bliver lavet uden overordnet arkitektur, eller fokus på performance, og så først senere når projektet er for stort til at du kan kode det om, bliver optimeret ved hjælp af f.eks. opcode cache, eller løsninger som denne her.
Der laves millioner af private hjemmesider og hjemmesider for små firmaer efter de principper.
Men et site som FaceBook har altså noget mere styr på deres ting. Ellers ville sitet slet ikke virke med den load.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund