maximale draagkracht PHP
Als je een grote applicatie moet opzetten, en daarmee is je draagvlak heel Nederland, vrij intensief, wat is dan de beste methode om een project op te zetten?
Ik denk zelf dat php op een gegeven moment de beperkende factor zal worden. Als je gigantisch veel page hits krijgt per dag, is het dan nog raadzaam om PHP te draaien? Kan PHP dat aan? ( niet kijkend naar technische specs..) maar de parser zelf. Wordt de applicatie dan traag en zoja, is het dan beter om het meteen vanaf het begin aan goed te doen en een taal kiezen met een compiler?
Graag jullie meningen!
Gesponsorde koppelingen:
en shared hosting voldoet dan ook niet he
zet gewoon een flink stel server bakken neer en gebruik zoveel mogelijk static of laat static content genereren
doe zo min mogelijk uit de database halen (caching!!!!!!!!)
verder moet je eens denken aan load balancing, aparte servers voor static content (zoals afbeeldingen) en een database cluster
verder over caching apc, zend optimizer/guard, memcache, ioncube en droom nog even verder veel succes
maar effe serieus waarop baseer jij dat je webapplicatie vanaf de start - of ooit een groot draagvlak gaat krijgen
edet: en waarom neem je zo'n opdracht aan als je nog geen flauw idee hebt wat de gevolgen van veel gebruikers zijn?
edet: wat is eigenlijk veel; 1 miljoen request?
edet: minimaliseer ook https want dat kost nogal wat rekenkracht
Je begrijpt hopelijk wel dat je een dergelijk groot project niet proceduraal meer kan op zetten maar je moeten gaan kijken naar OOP en werken met frameworks (Kohana is briljant, MVC en OOP (php5 )). Tevens zul je voor je database queries moeten kijken naar het gebruik van andere technieken dan de mysql_* functies. Bij Kohana kan je gebruik gaan maken van ORM of PDO (PDO altijd wel, niet alleen Kohana).
Oja includes, requires vreten; dus beperk ze of laat ze oplossen door allerhaden cache dingen merk op dat die meestal niet overweg kunnen met dynamische padden
Webmakerij schreef op 20.09.2009 11:08:
Afra over het algemeen is proceduraal qua run sneller; alleen het onderhoud is vrij zwaar; het geheugen wordt namelijk minder belast met opslaan van objecten (en bijbehorende overhead), abstracte lagen hoeven niet ingeladen te worden enz.
I know ;) Maar we willen mensen met grote ideeën niet gaan aanmoedigen precudraal te gaan scripten lijkt mij. Het kán, maar ik denk dat velen met me zullen instemmen dat OOP beter geschikt is.
Deels proceduraal kan best goed te onderhouden zijn.
Mr. Bean (loran) schreef op 20.09.2009 11:12:
Ga eens na Hyves is ook met php en die heeft ook een paar duizend mensen per dag er op, maar die hebben er ook een 3000 servers voor draaien, als het er niet meer zijn.
3000 servers? voor een paar duizend bezoekers? Denk dat Hyves wel meer trekt dan een paar duizend bezoekers... heb het maar over miljoenen hits per maand, maar 3000 servers???
Gewijzigd op 01/01/1970 01:00:00 door Rens nvt
Los van het feit of ik geschikt ben om een grote applicatie op te zetten of niet, wil ik gewoon weten in hoeverre PHP nog lekker draait in verband met de parser. Als je namelijk assemblies hebt, lijkt mij dit toch sneller te gaan dan wanneer alles steeds geparsed moet worden. Ook al zou je alles cachen ( zowel serverside als client side )
dan nog moet je (zoals Rens aangeeft ) miljoenen hits parsen en verwerken in je cache.
Dan gaat het toch sneller wanneer je data met binarycode terug geeft als het ook binary binnenkomt? Die parser moet dat eerst nog omzetten naar binary, dan die binary parsen, en vervolgens weer terug geven aan de browser.
Nu lijkt het mij ( ben momenteel bezig met kijken nar Java en C#) of dat een presatie winst geeft boven PHP.
Dat is mijn punt. Ik zeg volgens mij ook nergens dat ik zelf zo`n groot project doe of iets dergelijks webmakerij. En je opmerking
"duhuhuh verzin je hetzelf? tuurlijk wordt iets traag"
slaat nergens op, ik bedoel ik WEET dat het trager wordt, daarom begin ik er een fucking topic over. Toch wil ik je bedanken voor je comments. De rest ook. Maar dit is denk ik het verkeerde forum om over zulke prestaties te discussieren?
Het verwerken van de miljoenen hits is in het geval van juiste caching niet zozeer alleen een PHP ding trouwens, maar ook voor een erg groot deel afhankelijk van je webserver... En daar zit je met webapplicaties toch vrij snel aan vast ;-)
Tenminste, als beide ( zowel PHP als binary ) op 1 dezelfde server draaien, ( los van elkaar of wat dan ook.. :S )
Welke zou effectiever omgaan met snelheden? En dan wil ik cache nog niet mee rekenen. Ik wil gewoon weten of een parser trager is dan een binary code. Zeker als het gaat om grote hoeveelheden hits. Dus wat berekent een iets sneller.. een parser of een stukje binaire code?
En geen vage vergelijkingen met hosting rotzooi, ga gewoon uit van een gelijke installatie. Ook het verschil tussen objecten en proceduraal mogen niet meetellen. Kijk gewoon naar zoiets als een hello world script. Of wat dan ook.
Weet je wat, laat ook maar, jullie denken te veel. Jullie nemen alles mee in een vergelijking, dat moet ik helemaal niet hebben. Ik bedoel ik moet gewoon weten of binaire code sneller gaat dan een parser. Fuck hosting, fuck scripting methodes, fuck hardware.
Wat is sneller?
maarre, calm down, anders is de tijd waarbinnen je zelf overspannen bent het snelst...
Ik heb geen ervaring met Java / C via het web, maar parsen kost tijd. Vanuit dat oogpunt lijkt binair me sneller, maar dit is niet gebaseerd op tests o.i.d.
Maar eigenlijk stel je een retorische vraag, met een houding van lik me vestje, dus vraag me af of je je antwoord op deze manier wel gaat vinden...
Niet gebasseerd op installaties zoals hosting, server en dergelijke. Ik bedoel , de vraag is toch ook niet moeilijk? Wat is sneller: binaire code of geparste code?
Dan wil ik niet 8 comments die mij afzeiken omdat ik een vraag stel, en wil ik geen 3 comments terug zien omdat hyves zogenaamd zuigt of wat dan ook. Ik wil dan liever een discussie zien die gebasseerd is op mijn vraag.
Dus bij deze nogmaals:
Wat is sneller: binaire code of geparste code?
Merijn schreef op 20.09.2009 19:10:
Weet je wat, laat ook maar, jullie denken te veel. Jullie nemen alles mee in een vergelijking, dat moet ik helemaal niet hebben.
Zeg schat, jou vraag is een vergelijking. En dan mogen wij geen dingen vergelijken?
Des te dichter je bij de uiteindelijke hardware taal staat, des te minder stappen moeten worden ondernomen om iets uit te voeren, des te sneller iets is.
Uiteindelijk word php ook naar iets omgezet als binary code, dus dat betekent dat php dus langzamer zal zijn als binary code.
Maar natuurlijk moet de binary code wel goed geschreven zijn, anders kan het zijn dat de tijd om de binary code uit te voeren, langer is als dat php hem zou parsen en uitvoeren.
En voor de rest vind ik het heel logisch dat je alles meeneemt in een vergelijking.
Maar dat terzij,, dit moet je antwoord zijn.
Volgende puntje is echter wel: ga je kiezen voor een programmeertaal alleen op snelheid? Of MOET je gewoon andere factoren meenemen, als kosten, infrastructuur, clients, kennis, enz. enz. Het is dus niet zo gek dat wij hier extra dingen vergelijken. Al helemaal niet op basis van de lichtelijk uitgebreide vraagstelling t.o.v. 'Wat is sneller: binaire code of geparste code?'
@karl: nee ik vraag niet om een vergelijking, ik vraag om een antwoord van een vergelijking.
@rens: En als je weet wat retorisch betekent, weet je ook dat je het in de verkeerde context hebt geplaatst.
Maar nogmaals, ik ben blij dat jullie reageren, maar jullie btrekken er te veel bij. Nico geeft echter gewoon antwoord op mijn vraag. Dat antwoord zocht ik. Gewoon iemand die mij vertelt wat sneller is. Natuurlijk WEET ik dat er zaken meespelen, maar ik moest gewoon weten wat sneller is. Thats all folks!
Bedankt allemaal, leuke discussie ;)
