Facebook-ontwikkelaars bouwen php-versneller

De hiphop runtime is ook een webserver. Ik verwacht dat je in een productieplatform iets als nginx, lighttpd of apache als reverse-proxy ervoor zet en die tevens de statische content doet.

ik vraag mij echter af welke webservers die C++ binaries begrijpen en verwerken.

Alle webservers die CGI ondersteunen (ie: zo'n beetje alle serieuze webservers op aarde)?

Waarschijnlijk zal voor dit systeem een plugin/extensie in IIs/Apache geladen moeten worden.

mod_cgi op Apache, onderdeel van de standaard distributie

Bedoel je Classic ASP of ASP.NET ?

En welke omweg bedoel je dan ?

Let wel: ASP en ASP.NET zijn twee totaal verschillende technieken, en hebben eigenlijk op de naam na niets overeenkomstig.

(Ok, er zijn ook nog paar objecten hetzelfde genoemd zoals de request zodat je met ongeveer dezelfde syntax hetzelfde kan bereiken, maar achter de schermen is het totaal anders)

Hangt er echt vanaf hoor. Want met ASP op een IIS server aan een MSSQL database heb je juist heel veel mogelijkheden, ik zou dat hardly omwegen willen noemen. Rechtstreeks toegang tot stored procedures, bijvoorbeeld.

Oke, wist ik niet. Weer wat geleerd vandaag. Erg mooie ontwikkeling als je zo de load van je servers kan verminderen en de performance van je scripts kan verhogen .

Ze werken aan native Apache-ondersteuning.

However zou het in de linux wereld geen ramp zijn om bv. de source code van een open source pakketje te verdelen via rpm/deb. Closed source wereld zal er meer last van hebben.

Het probleem was niet zo zeer de traagheid van de scripts als de load op de servers, als je plotseling van uit een kleine hosting server groeit naar een setup met vele servers en heel erg veel database requests dan kom je al snel op een probleem waar je database(s) niet zo maar mee overweg kunnen. In het filmpje meld men dat er 400 miljard pageviews voobij komen op de Facebook servers. Natuurlijk zal Hyves niet zo groot zijn maar met een onstuimige groei zo als bij hyves zul je snel moeten opschalen en dat is niet makkelijk. Al is het alleen al dat je aan database proxies moet gaan denken en dingen als caching van data en tables of query results.

Hyves is in middels een stuk beter en ik weet zeker dat dat meer gebaseerd is op hardware scalling. Het is nu eenmaal moeilijk om even snel zeg 1000 webservers op te zetten en gewoon even aan je database the hangen. Met deze oplossing zullen ze niet zo snel een veel snellere oplossing hebben maar eerder minder servers nodig hebben en dat is het belangrijkste minder kosten met de zelfde hoeveelheid pageviews en gebruikers. De extra executie snelheid wordt tenietgedaan door de latency op het netwerk, zeker als je bedenkt dat een pagina waarschijnlijk niet meer dan een paar milliseconde draait, als je van de 8 naar de 4 milliseconde gaat dan heb is er niemand die het zal merken omdat het al snel 20 miliseconde duurt voor de packets bij jouw zijn aan gekomen.

Met andere worden het is groen (minder servers met de zelfde performance is minder vervuiling) en minimaal net zo belangrijk het is lekker goedkoop wat betreft hardware, want groen is leuk maar meer dollars (ook groen btw) in je zak is veel belangrijker natuurlijk.

Ik ken maar weinig licenties die stellen dat je de code altijd openbaar moet maken. Zelfs de GPL, welke toch wel als meest strict/open wordt beschouwd, stelt dat je je code alleen beschikbaar moet maken als je de binaries gaat distribueren. Als jij zelf de tool gebruikt voor eigen gebruik distribueer je niks, en hoef je dus ook niets open te maken.

Van het volgende ben ik iets minder zeker, maar volgens mij zouden ze als de software gedeeltelijk onder gpl valt, zelfs een service mogen aanbieden om voor andere bedrijven hun php source gecompileerd weer terug te geven, aangezien je hier niet de tool distribueert maar alleen het resultaat.

Smalltalk is een van de puurste OO talen die ik ken en is tevens weak-typed.

Waek typing zegt niets over het wel of niet OO zijn van een taal. Net als strong-typing heeft weak-typing zijn voor en nadelen maar dat maakt het een of het ander niet minder of meer geschikt voor OO.

@s.stok: of je post is per ongeluk onder mijn post komen te hangen of je hebt mijn post niet goed gelezen. Ik probeer alleen maar uit te leggen dat static of dynamic typing niet bepaald of een taal OO is of niet.
Ik wist overigens niet dat php beide ondersteund maar het klinkt mij als een slecht idee. Je kunt twee style dwars door elkaar heen programmeren wat de leesbaarheid niet ten goede komt en je krijgt daarnaast de nadelen van beide typeringen op de koop toe.

[Reactie gewijzigd door sys64738 op woensdag 3 februari 2010 14:18]

Java en C# zijn veel object georienteerder dan C++. C++ biedt er ondersteuning voor maar dringt het niet op; in Java kan je gene programma schrijven zonder een class te maken.

Dat wat voor C++ geldt geldt ook voor PHP; het kan, maar hoeft niet. En zowel in C++ als in PHP heb je prima methoden om erachter te komen met wat voor object je werkt, type-strong of niet. Bij PHP heb je alleen meer mogelijkheden om daar op run-time pas achter te komen terwijl in C++ het grotendeels bij compile-time al duidelijk moet zijn.

Denk dat jij ook nog veel te leren hebt. OO is een andere manier van denken, maar zeker geen sleutel tot performance en/of efficiency.

OO is een denkwijze.

Als je denkt dat zoiets de key tot performance is, moet je even nadenken over het feit dat onderwater een computer helemaal niets afweet van classes. Niets meer dan een reeks aan data en CPU instructies.

We kunnen natuurlijk allemaal in assembler gaan coden. Dan krijg je echt snelle en efficiënte programma's van.

Het onderhouden en bugs vrij houden van de code is dan alleen een ander verhaal.

Ja ok, mijn formulering was wat scheef. PHP is een object georienteerde taal omdat ie je actief helpt bij het schrijven van OO programmatuur.

Persoonlijk schrijf ik toch liever OO programma's in een OO taal dan dat ik alle plumbing zelf moet doen.

Hoeft niet. OO is een manier van denken. Programmeertalen bieden enkel mogelijkheden om OO makkelijker te programmeren.

Inderdaad. Gaarne had ik Wousert eens zien OOP bronselen in ASM of zelfs C.

Nou ja, ik bedoel meer deserialisation natuurlijk. Je laadt een object uit een string, maar wat voor object is het? In PHP hoef je je daar niet druk over te maken, maar C++ doet dat natuurlijk wel, in ieder geval wel als er een 1-op-1 relatie tussen een PHP-class en een C++-class bestaat.