Udvikler: Facebooks PHP på steroider er unødvendig
Det forlyder fra flere sider, at Facebook vil præsentere et nyt, højtydende PHP-miljø tirsdag. Men Troels Knak-Nielsen, som er PHP-udvikler i Peytz & Co, kan ikke lige se et stort behov for Facebooks kommende nyskabelse.
Han gætter på, at Facebooks kørselsmiljø bygger på en compiler, der oversætter til "født" kode, som når man kompilerer C. Zend Optimizer, som er et eksisterende produkt til at sætte fut i PHP, fungerer i modsætning hertil ved at gemme den opcode, som PHP-koden kompileres til.
»Den måde, man klarer sig rundt om ydelsesproblemer, er ved at sørge for, at der ikke er nogen tilstand i selve PHP-leddet, så man kan skalere ud på flere servere. Hvis man har en applikation som Facebook, så kan det være dyrt at købe en million nye servere, men for de fleste er det ikke noget problem at købe en ekstra webserver.«
Troels Knak-Nielsen desuden peger på, at der findes mange store applikationer som kører på PHP uden dikkedarer.
»I Wikipedia er det for eksempel ikke PHP, der er flaskehalsen. Der er problemet at få centraliseret data og distribueret dem rundt.«
Hvis man har behov for at optimere ydelsen til en konkret anvendelse, kan man skrive en udvidelse i C. Sådan ville Troels Knak-Nielsen gøre, hvis behovet opstod.
I modsætning til sprog som Python og Ruby har PHP-miljøet formået at holde sig til et enkelt kørselsmiljø, og Troels Knak-Nielsen tror, at det vil det blive ved med.
»Det er interessant, så længe det er nyt, og så vil det nok dø ud igen.«
Det er i øvrigt ikke så nemt at implementere et komplekst sprog som PHP, der gør det muligt at evaluere koden dynamisk.
Kommentarer (14)
Er det en dårlig oversættelse af "native code" ?
Skriv evt. maskinkode, hvis det absolut skal oversættes.
-
0 -
0
Wikipedia har ca. 350 servere. Det kunne nok spare en del penge med en mere effektiv afvikling af systemet.
Det siges at Facebook har omkring 30.000 servere. Det burde nok kunne betale for lidt optimeringsarbejde.
Man kan antage at Facebook allerede har gjort de tiltag er nævnes i artiklen, men nu ønsker at få det sidste med også.
Selv administrerer jeg et lille website for en forening, som til tider er lidt for langsomt. Hvis Facebook kommer med et nyt PHP kørselsmiljø som jeg nemt kan sætte ind, og få bare en smule længere levetid på serveren, så tager jeg da imod det. Jeg er ikke sikker på at vi har råd til en ny server.
Det største problem ved at oversætte PHP til maskinkode er i øvrigt at det ikke er statisk typet. Det medfører at programmet skal lave langsomme typecheck på kørselstidspunktet i stedet for i oversættelsesfasen.
-
0
-
0
"maskinekode" er vel heller ikke passende, "platform specifik kode" vil imho. være mere passende.
-
0
-
0
Det er i øvrigt ikke så nemt at implementere et komplekst sprog som PHP, der gør det muligt at evaluere koden dynamisk.
Oversætter jeg til "PHP er noget proprietært skudder mudder, som nok er udviklet organisk og mangler en egentlig grammatik"
-
0
-
0
Umiddelbart virker Troels Knak-Nielsens udtalelser som noget tynde. Facebook benytter svjv en distribueret database (Cassandra), så udtalelsen omkring wikimedias opsætning virker umiddelbart lidt malplaceret.
Man kan vel heller ikke forvente at en tilfældig, gennemsnitlig kodekarl kan give en særlig detaljeret analyse af noget som nok er i nærheden af at være verdens største website.
-
0
-
0
Kan kun være helt enig med Baldur Norddahl, alle forbedringer af et programmeringssprog er velkomne, men personligt så jeg hellere at Facebook og The PHP Group arbejdede sammen om at forbedre den kommende PHP 6.0 end at vi skal til at installere forskellige extensions (om de hedder Zend eller Face).
-
0
-
0
Nej, den konkrete kommentar virker på mig mest til at PHP inkluderer en eval() funktion der gør det muligt dynamsik at generere kode og få det udført i samme process.
Det har hverken noget med om PHP er proprietært, "skudder mudder", organisk udviklet eller mangler en velbeskrevet grammatik.
-
0
-
0
Det var nu mest ordet "komplekst" som fik mit knæ til at spjætte.
En eval konstruktion er vel heller ikke det værste man kan komme ud for.
-
0
-
0
Har du en PHP cache på webserveren? Ellers kan du vinde rimeligt godt på f.eks. APC som jeg har rigtigt gode erfaringer med fra mit arbejde. Der findes også Eaccelerator som faktisk er en smule mere effektiv end APC, men den har jeg haft nogle stabilitetsproblemer med...
Jeg har selv et webcluster med 20 webservere som stort set kun leverer PHP. Der fik jeg halveret load ved at bruge en PHP cache...hvis man kan vinde mere ved lidt flere ændringer er det da sejt, men jeg vil nok kun benytte det så fremt PHP selv accepterer ændringerne og releaser dem.
/Anders
-
0
-
0
personligt så jeg hellere at Facebook og The PHP Group arbejdede sammen om at forbedre den kommende PHP 6.0
Målene er nok for forskellige til at det er realistisk. PHP 6.0 har fokus på nye features, Facebook skal bruge ydelse, og har muligvis valgt slet ikke at implementere store dele af PHP 5.3. Men det er jo fint muligt at Facebook i fremtiden vil implementere PHP 6.
En eval konstruktion er vel heller ikke det værste man kan komme ud for.
Fra et compiler synspunkt er det faktisk ret eksakt det værste man kan komme ud for. Der skal implementeres en hel virtuel maskine og namespacet skal bevares og kunne udvides. Det kan lade sig gøre, men det er en kæmpe mængde ekstra arbejde.
-
0
-
0
[quote]En eval konstruktion er vel heller ikke det værste man kan komme ud for.
Fra et compiler synspunkt er det faktisk ret eksakt det værste man kan komme ud for. Der skal implementeres en hel virtuel maskine og namespacet skal bevares og kunne udvides. Det kan lade sig gøre, men det er en kæmpe mængde ekstra arbejde[/quote]
Antag du vil implementere eval for sproget C på en Unix maskine.
Eval funktionen skriver sit argument til en temp fil, for eksempel /tmp/eval.c. Derefter kaldes "gcc" compileren. Sidst hentes resultatet ind med systemkaldet dlopen.
Jeg kan nok komme i tanke om værre ting at implementere :-).
-
0
-
0
Eval funktionen skriver sit argument til en temp fil, for eksempel /tmp/eval.c. Derefter kaldes "gcc" compileren. Sidst hentes resultatet ind med systemkaldet dlopen.
Så vidt jeg ved eksekvere PHP eval i det scope den befinder sig i, hvilket betyder at den fremgangsmåde ikke er særlig realistisk. Der er en grund til at man normalt går i en stor bue uden om eval-funktioner når der snakkes statisk analyse :)
-
0
-
0
Det vil ikke tage meget at forbedre metoden til også at virke med variabler i samme scope. Det kræver dog lidt hjælp fra oversætteren. Metoden giver allerede adgang til globale variabler. For at give adgang til lokale variabler, så skal oversætteren af eval blokken have en reference til et kort over stakken i den kaldende funktion. F.eks. LLVM indeholder metoder til at lave den slags kort over stakken.
-
0
-
0
Troels Knak-Nielsen desuden peger på, at der findes mange store applikationer som kører på PHP uden dikkedarer.
Ganske givet rigtigt, men ikke nødvendigvis relevant ifht spørgsmålet omkring Facebook's PHP.
»I Wikipedia er det for eksempel ikke PHP, der er flaskehalsen. Der er problemet at få centraliseret data og distribueret dem rundt.«
Wikimedia benytter MySQL i clusters med yderligere caching af forespørgsler, så vidt jeg husker. Facebook benytter Cassandra, som nok skalerer langt nemmere. Argumentationen er ikke relevant.
Hvis man har behov for at optimere ydelsen til en konkret anvendelse, kan man skrive en udvidelse i C. Sådan ville Troels Knak-Nielsen gøre, hvis behovet opstod.
De fleste kigger forhåbentlig andre steder førend de tyr til C. Umiddelbart mener jeg også at Donald Knuth er enig.
I modsætning til sprog som Python og Ruby har PHP-miljøet formået at holde sig til et enkelt kørselsmiljø, og Troels Knak-Nielsen tror, at det vil det blive ved med. »Det er interessant, så længe det er nyt, og så vil det nok dø ud igen.« Det er i øvrigt ikke så nemt at implementere et komplekst sprog som PHP, der gør det muligt at evaluere koden dynamisk.
Der er i denne kontekst intet som angiver at "ikke så nemt at implementere" betyder statisk oversættelse. Uanset dette, vil jeg stadig fastholde at det er sværere at oversætte et svagt dokumenteret og unødigt kompliceret sprog end at implementere en eval konstruktion.
Men som Baldur skriver: Oversætteren ved jo godt, hvor der findes en eval blok. Det er ikke svært at lave et "symbol map" til brug ved udførelse af eval blokken. Nemmere end så meget andet. Nemmere end at skrive en PHP oversætter.
-
0
-
0
