[Zend FrameWork] Hoe snel is Zend Framework bij jou?

[Verwijderd]

Binnenkort gaan we live met de nieuwe versie van onze Website. We hebben de nieuwe versie ontwikkeld op Zend Framework. We hebben gebruik gemaakt van Zend_cache, het MVC model, onze eigen partials en view helpers.

Ook hebben we met FireBug en FirePHP de database queries geoptimaliseerd ( < 0,0001 sec). Toch vind ik zend framework vrij traag laden. Gemiddeld liggen de parse tijden van de pagina tussen de 0.1 en 0.5 seconden. Dit terwijl onze oude functie gebaseerde website, de paginas gemiddeld op 0.0005 seconde genereerd.

We hebben ook al de PluginLoader cache ingesteld, maar dit maakt ook nog niet veel uit.

Ik heb het idee dat de grootste bottleneck het MVC model is. Wanneer ik de layout en de views leeg laat, dan komt de parsetijd onder de 0.1 seconde. Nog vind ik de parse tijd dan traag.

Vandaar dat ik benieuwd bent naar andere ervaringen en misschien wel oplossingen.

Groeten Bert

[Voutloos]

Meten = weten, en profilen van de backend doe je niet dmv firebug. Installeer xdebug en gebruik een tool als webgrind.

Puur een gokje als hint: heb je wel een opcode cache?

[-DarkShadow-]

Zend Framework is vrij traag, dat ligt niet aan het MVC model. Er zijn genoeg frameworks die wel snel zijn en ook het MVC model implementeren (zoals Yii). Heb je de Zend server al geprobeerd?

[drm]

Voutloos:
Puur een gokje als hint: heb je wel een opcode cache?

Was ook mijn eerste ingeving. De hoeveelheid classes die ingeladen worden is niet gering, en aangezien het 1 class per file is binnen ZF, kost een gemiddelde request je veel meer disk I/O dan wanneer je niet een dergelijk framework gebruikt. Probeer APC eens.

[Voutloos]

Overigens is het dusdanig vaak nuttig dat het compleet stupide, achterlijk en enorm 1995 is dat het niet standaard aan staat / ingebakken is.

[ Voor 5% gewijzigd door Voutloos op 28-03-2011 23:20 ]

[kwaakvaak_v2]

Het is meer stupide dat ZF zo achterlijk veel files nodig heeft omdat ze voor elke drie functies een apparte class aan moeten maken. Dat is pas overhead

[ZpAz]

Iets met loose coupling en high cohesion.

[Cartman!]

Dat wil ik niet stupide noemen, het is juist compleet OO opgezet en volgens een bepaalde structuur dat iedere klasse een eigen file is voor de autoloader en als nadeel heeft het de hoeveelheid files.

Persoonlijk gebruik ik de autoloader niet en require ik de boel handmatig, voor m'n eigen gevoel zou dat al sneller moeten zijn hoewel ik er geen bron voor kan vinden

[mithras]

Er zijn een aantal dingen in ZF die het een gebruik sterk vereenvoudigen, maar wat vervolgens (helaas) ten koste gaat van snelheid. Het grote voorbeeld: Zend_Application. Het gebruik van een application.ini met application resources tijdens bootstrap werkt geweldig, maar helaas gaat dat ten koste van je response time.

Er zijn de nodige tweaks te vinden online (afschaffen Zend_Application, slimmer omgaan met dispatch, include paden etc), maar die kan je pas goed toepassen wanneer je weet waar de bottleneck zit. En daarom: meten = weten. Dus pak xdebug erbij en kijk wat écht lang duurt

[kwaakvaak_v2]

OO dwingt een bepaald file/folder patroon absoluut niet af.. (net zo min, dat OO de heilige graal der programmeren is, maar dat is een andere discussie )

Persoonlijk gebruik ik de autoloader niet en require ik de boel handmatig, voor m'n eigen gevoel zou dat al sneller moeten zijn hoewel ik er geen bron voor kan vinden

Dat kan ZF ook voor je bij houden, dat is namelijk precies wat die loader cache doet, en ja dat scheelt behoorlijk in performance omdat er dan niet bij elke hit gezocht moet worden waar die file zich precies bevindt in het oerwoud der files

[FragFrog]

Cartman! schreef op dinsdag 29 maart 2011 @ 10:16:
Persoonlijk gebruik ik de autoloader niet en require ik de boel handmatig, voor m'n eigen gevoel zou dat al sneller moeten zijn hoewel ik er geen bron voor kan vinden

Hoewel je gelijk hebt dat de autoloader (in mijn tests) langzamer is, kun je dat vrij eenvoudig cachen. Juist doordat dat simpel kan dankzij de autoloader haal ik een betere performance met veel includes Mind you, ook zonder caching zijn alle includes toch wel met een 40, 50ms klaar. Als ZF er langer over doet wordt het tijd te gaan profilen (en wellicht ook eens je disk performance te meten).

[Cartman!]

Voor het cachen van requires heb ik al de APC-extensie, ik denk dat die dat behoorlijk sneller doet dan een stukje cache in code binnen PHP eigenlijk. Ik zal het stukje wel even doorlezen iig, bedankt

kwaakvaak_v2 schreef op dinsdag 29 maart 2011 @ 10:27:
Dat kan ZF ook voor je bij houden, dat is namelijk precies wat die loader cache doet, en ja dat scheelt behoorlijk in performance omdat er dan niet bij elke hit gezocht moet worden waar die file zich precies bevindt in het oerwoud der files

Dat hoeft dan ook juist niet, ik require een volledig pad vanaf de webroot. De stap zoeken is dus volledig weggenomen dan volgens mij.

[ Voor 55% gewijzigd door Cartman! op 29-03-2011 10:52 ]

[FragFrog]

Cartman! schreef op dinsdag 29 maart 2011 @ 10:51:
Voor het cachen van requires heb ik al de APC-extensie, ik denk dat die dat behoorlijk sneller doet dan een stukje cache in code binnen PHP eigenlijk.

Als je dat gaat meten graag posten, ik vermoed dat je gelijk hebt maar ben er zelf nog niet aan toe gekomen het te testen _{vooral omdat ik nog steeds niet de extensie op m'n development bak geinstalleerd heb}

[ Voor 11% gewijzigd door FragFrog op 29-03-2011 11:03 ]

[Cartman!]

Harde cijfers heb ik niet maar in de meeste projecten bij ons zorgt het aanzetten van APC voor een boost van 80% in views wat een site aankan. We hebben dan wel de "stat" functie nog aanstaan, als je die uitzet zou t nog sneller zijn. Die functie controleert namelijk nog of de file gewijzigd is, als je dat dus uitzet dan zal je geen wijzigingen zien in je files totdat je de webserver herstart of de cache leegt.

[mithras]

Cartman! schreef op dinsdag 29 maart 2011 @ 10:16:
Dat wil ik niet stupide noemen, het is juist compleet OO opgezet en volgens een bepaalde structuur dat iedere klasse een eigen file is voor de autoloader en als nadeel heeft het de hoeveelheid files.

Dat is inderdaad niet per sé OOP, maar de PEAR naming convention die klasse scheidt met folders (op bestandsniveau) en underscores (op klasse-naamgeving-niveau).

Cartman! schreef op dinsdag 29 maart 2011 @ 11:07:
Harde cijfers heb ik niet maar in de meeste projecten bij ons zorgt het aanzetten van APC voor een boost van 80% in views wat een site aankan. We hebben dan wel de "stat" functie nog aanstaan, als je die uitzet zou t nog sneller zijn. Die functie controleert namelijk nog of de file gewijzigd is, als je dat dus uitzet dan zal je geen wijzigingen zien in je files totdat je de webserver herstart of de cache leegt.

Omdat je met absolute paden werkt, kan je dus écht een grote boost krijgen. Probleem met stat en APC inclusief relatieve paden is dat alsnog het pad geresolved moet worden. Wanneer je met absolute paden werkt, is dat probleem verholpen.

Gelukkig komt met ZF2 een classmap autoloader, die een mapping vormt tussen klasse en bestanden, waardoor je als een razende alle klasse kunt vinden

[Slurpie]

Je kan gelukkig in Zend een hoop dingen wegdoen als je het niet gebruikt.
Daarbij kan overloading van bepaalde classes handig zijn om bepaalde dingen te cachen die je constant gebruikt.

En het leeg laten van views, tja gooi 400 kb aan html in een view dan duurt het wel even voordat deze is geladen.

[Cartman!]

Slurpie schreef op dinsdag 29 maart 2011 @ 11:17:
Je kan gelukkig in Zend een hoop dingen wegdoen als je het niet gebruikt.

Je hoeft het niet perse weg te gooien, zolang jij t niet inlaadt neemt het enkel een paar MB ruimte in en zal je er nooit hinder van ondervinden.

@mithras: precies, daarom gebruik ik altijd absolute paden

[Verwijderd]

Wat zou je dan nog moeten gaan cachen?

Wij gebruiken cache voor het cachen van database requests. Echter dit is dus niet de grootste bottleneck. Aangezien de database queries zeer snel worden afgehandeld.

En wat ik me nog steeds afvraag, hoe snel is zend framework als het geoptimaliseerd is?

[ Voor 17% gewijzigd door Verwijderd op 29-03-2011 12:04 ]

[Cartman!]

Pagecache in Zend_Cache is ook top mits je het kan gebruiken (statische content), misschien iets voor jullie? Of het cachen van enkele losse onderdelen kan ook enorm zin hebben.

Wat ook goed kan werken, je pagina zelf statisch serveren en via xhr de account-specifieke content inladen.

[Slurpie]

Cartman! schreef op dinsdag 29 maart 2011 @ 11:58:
[...]

Je hoeft het niet perse weg te gooien, zolang jij t niet inlaadt neemt het enkel een paar MB ruimte in en zal je er nooit hinder van ondervinden.

ZF laad zelf ook bepaalde dingen standaard in, die eventueel niet gebruikt worden. Die zou je ook kunnen verwijderen. Daarbij Als je het niet gebruikt waarom zou je het erbij zetten, het scheelt een hoop kleine bestanden op je server.

Verder kan je de layout cachen, waar onder je css en js files. Wordt er toch minder over je schijf heen gezocht.

[nika]

Let je er wel op dat je geen forwards etc. doet? Dan wordt namelijk de hele request chain opnieuw opgestart.

[drm]

Voutloos:
Overigens is het dusdanig vaak nuttig dat het compleet stupide, achterlijk en enorm 1995 is dat het niet standaard aan staat / ingebakken is.

offtopic:
Klopt Freeaqingme wist van de week te vertellen dat er wel plannen zijn om het standaard in PHP5.4 te stoppen. Dat is wel interessant want dat betekent ook dat het zin gaat hebben om compileroptimalisaties te doen enzo. Zou helemaal cool zijn als er dan nog een C-style preprocessor ingezet gaat worden waarmee je debuginfo in je code kan stoppen, die vervolgens in een live-omgeving niet meegecompiled wordt Dat laatste is overigens een ideetje © Cheatah.

klandermans:
Wat zou je dan nog moeten gaan cachen?

Weet je wel wat bedoeld wordt met een opcode of bytecode cache?

[Verwijderd]

drm schreef op dinsdag 29 maart 2011 @ 12:09:
Weet je wel wat bedoeld wordt met een opcode of bytecode cache?

We weten wat het verschil is, maar we vragen ons af hoe we hier performance winst i.v.m. zend optimizer+ kunnen halen.

[Freeaqingme]

Heb je al de ZF performance guide doorgenomen?

Daarnaast, heb je voordat je ging cachen wel gekeken of dat een bottleneck veroorzaakte? Het ophalen van data uit je cache, en die deserializen neemt ook tijd in beslag. Hierdoor kan het gebeuren dat zonder cache de boel sneller is dan met.

Verder, ik neem aan dat je wel met iets als AB timet?

[ReenL]

Zend Framework is inderdaad niet zo snel in opstarten. Dit komt door Zend_Application maar ook door de zogenaamde "dispatch-loop". Dit willen ze in ZF2 gaan verbeteren.

Ik heb geen meetgegevens maar controleer de "short-tags" optie van php is te enablen (als dit niet het geval is), dan hoeft hij geen stream wrapper meer te registreren en elke view te preggen voordat hij begint met parsen. Ik denk dat dit zeker nut heeft bij grote layouts/views.

[ameesters]

Hmmm, je kan ook geen framework gebruiken...
Op een bepaalde summit heb ik onlangs iets geleerd over wat ze noemen "Outside in" ontwikkelen.

Dat hou in dat een mens vanuit naturen eerst problemen voor zich zelf willen oplossen(een framework) en daarna pas gaan beseffen dat andere mensen het ook nog moeten gaan gebruiken.

Bij "outside in" ontwikkelen doe je dat niet, daar ga je vanuit de eindgebruiker kijken welken problemen zij kunnen tegen komen en hoe je dat op lost...

misschien een beetje te laat nu, maar misschien wel iets wat je de volgende keer rekening mee kan houden...
aangezien het nu voor een probleem zorgt bij je eindgebruikers die je anders niet had gehad...

[Verwijderd]

inderdaad, een ander framework is geen optie. En ik ben ook best tevreden over de structuur die zend framework me bied binnen de applicatie. Dit was voordat we op deze manier gingen werken veel onduidelijker.

@ Freeaqingme, wat is AB wat je aanbeveelt om te timen?

[storeman]

@leipepo

Ik kan je punt begrijpen, maar ben het er niet mee eens. Ja, een framework zorgt voor overhead, maar dit weegt niet op tegen de voordelen. Voornamelijk de schaalbaarheid, onderhoudbaarheid en de ontwikkeltijd. Een ontwikkelaar die reeds bekend is met een framework kan vrij snel ingezet worden in een willekeurig project, voor ontwikkeling of onderhoud. Een framework wordt door veel mensen onderhouden, dit levert voordelen op met betrekking tot veiligheid en documentatie (wat weer terugkomt in ontwikkeltijd). Een goed framework kun je daarnaast altijd inzetten voor meerdere applicaties, wat ook erg prettig is.

Extra hardware kost maar een fractie van de uren die men bezig kan zijn met het zoeken/oplossen van problemen, onderhoud en ontwikkeltijd.

Ik loop overigens ook aan tegen de performance van ZF. Ik ben nu een aantal projecten hierop aan het draaien en zit er sterk over te denken maar eens wat dieper de performance in te duiken. Er moet toch wel wat winst te behalen zijn her en der.

Ik heb ooit een keer een benchmark gezien van verschillende frameworks, hier kwam ZF vrij slecht uit. Vervolgens stripten ze alle frameworks tot basis MVC (geen plugins etc). Vervolgens was ZF het snelst. Altijd een afweging, performance vs vriendelijk programmeren.

[ Voor 25% gewijzigd door storeman op 29-03-2011 22:49 ]

[RobIII]

leipepo schreef op dinsdag 29 maart 2011 @ 21:59:
Dat hou in dat een mens vanuit naturen eerst problemen voor zich zelf willen oplossen(een framework) en daarna pas gaan beseffen dat andere mensen het ook nog moeten gaan gebruiken.

Wie zegt dat in dit geval Zend een verkeerde keuze was? Misschien is de keuze uiteindelijk ("outside in") wel bij Zend uitgekomen?

En daarbij: ik denk dat je dat outside-in niet helemaal begrepen hebt zoals het bedoeld werd Als je het hebt over UX niveau (waar het over ging) dan is het weinig relevant of je er framework X, Y of Z tegen aan smijt; als je maar vanuit de UI denkt richting code en niet vanuit de code richting UI denkt

[Freeaqingme]

Ik mag dan ZF contributor zijn, maar ik denk dat /juist/ bij een framework als ZF, wat een component framework is, je dit wel altijd naar je zin kan krijgen. Ook is wellicht dit leuk om te lezen: Why you should never reinvent the wheel.

Dat hou in dat een mens vanuit naturen eerst problemen voor zich zelf willen oplossen(een framework) en daarna pas gaan beseffen dat andere mensen het ook nog moeten gaan gebruiken.

Met alle respect, maar dan weet je niet hoe een framework als ZF ontwikkeld wordt. Iemand stelt een bepaald component voor, de gehele community krijgt de kans daarop te reageren, en zijn/haar mening op dit voorstel te geven. Vervolgens kan het voorstel hierop worden aangepast, en pas als het grootste deel van de community geen bezwaar meer heeft wordt 't voorstel geaccepteerd.

@ Freeaqingme, wat is AB wat je aanbeveelt om te timen?

AB is een veelgebruikte app om websites mee te stresstesten. Op zich maakt het niet per se uit welke tool je gebruikt om te benchmarken, maar er zit een verschil tussen of je bij wijze van spreke in firefox 1 keer een pagina laadt, of 100 keer achter elkaar dezelfde pagina laadt om ook het effect van caches te kunnen testen. En zoals gezegd, installeer APC, dat is stap 1 in iedere serieuze php setup.

[Verwijderd]

wat is dan beter om te gebruiken? Zend optimizer+ of APC file cache.

En is het installeren van APC op je webserver voldoende? Of moet je in je Zend Configuratie ook nog het e.e.a. instellen.

[Cartman!]

Zend Optimizer heb je toch enkel iets aan bij files die gecompiled zijn tot bytecode? APC heb je altijd iets aan zover ik weet.

[Freeaqingme]

Ik zou het sowieso benchmarken. Meten = weten.

[Verwijderd]

We werken juist met zend optimizer+ omdat dit een opcode en bytecode PHP cache is. Zend Optimizer+ maakt gebruik van opcode caching, en plaatst gecompileerde code in de byte code cache.

Alleen merk ik met mijn benchmarks er vrij weinig van een verbetering en blijven de parstijden boven de 0,1 seconde.

[Freeaqingme]

Ja, en daarom zeg ik ook dat je enkel kan weten of APC beter voor je is als je benchmarkt. Daarnaast, heb je nou al geprofiled en gekeken waar 't aan ligt, en gekeken of 't zonder bep. caches juist sneller is? Deserializen kost ook tijd...

[ameesters]

laat ik mezelf toch wat beter onderbouwen(note to mod: als dit teveel offtopic is mag je het ook weg halen)...

Maar, wat ik dus bedoel is:
Er wordt een beslissing gemaakt om een framework te gebruiken, omdat hier veel tijdswinst te behalen valt in het ontwikkelen, zoals meerdere mensen al aan gaf. Dit neemt veel problemen uit handen voor de devvs, ok prima..

Vervolgens klagen de eind-gebruikers over snelheid problemen, waardoor de devvs een caching laag moeten introduceren, terwijl er als men er van uit ging van de eindgebruikers(outside-in) dit niet gebeurd was, of niet nodig was geweest...

Tevens vraag ik me af hoe iemand op een framework uit kan komen bij outside-in, want, door meerdere lagen te introduceren in je code, duurt een request langen, dus je moet zoveel mogelijk lagen zien te voorkomen en ze pas echt toevoegen als ze echt noodzakelijk zijn voor je eindgebruikers(dus niet voor jezelf (inside-out))

wat ik zelf zou doen is een tmpfs aan maken, daar de bestanden in gooien, dan zorgt het os er voor dat het compleet vanuit de geheugen draait, waardoor je disk io in ieder geval niet meer de bottleneck is, en geen meerdere lagen introduceert...

Tevens vind ik ook dat als je gediciplineerd een MVC pattern toepast, je geen framework nodig heb.

(nogmaals excusses voor deze complete offtopic, ik weet dat de TS hier niks (meer) aan heeft)

Verder is dit niet bedoeld om frameworks proberen af te zagen, gewoon mijn visie over het programmeren...

[mithras]

^^ waar héb je het over? Het lijkt op het zelfde geblaat als http://leipepo.com/?p=10, eerlijk gezegd. Als je geen idee hebt waarom je meerdere lagen in een applicatie introduceert, zou ik je aanraden eerst daar naar te gaan kijken.

Je komt over als een kip zonder kop, niet wetende wat je wilt, waar je naar toe wilt en wat daarbij precies je boodschap is. Lees eens een catalogus van patterns voor enterprise applicatie architecturen door. Of lees wat of scalability of maintainability. Dat zijn de echte onderwerpen (in mijn ogen) als je praat over software engineering. De inside-out/outside-in werkt op een heel ander niveau, zoals RobIII ook al aangeeft.

[gibraltar]

In het verleden heb ik een eigen (grote) webapplicatie wel eens geprofiled met Xdebug en KCachegrind. Nu ligt het aan de applicatie, maar over het algemeen zijn het toch echt maar twee dingen die een PHP applicatie langzaam maken: het parsen van PHP code en het uitvoeren van SQL.

En bij twijfel gewoon eens een keer profilen. Je leert hoe je applicatie werkt en als je de oorzaak niet weet, kun je wel blijven gokken naar de juiste oplossing. Sowieso is een opcode cache als APC gewoon altijd een aanrader omdat het geen invloed heeft op je applicatie en aanzienlijke snelheidswinsten oplevert.

Overigens kan ik mij nog een discussie herinneren op de PHP developer mailinglist over 't standaard includen van een opcode cache in PHP6. En wat mij betreft zeker geen overbodige luxe voor de wat grotere webapplicaties.

[ameesters]

mithras schreef op vrijdag 01 april 2011 @ 17:10:
^^ waar héb je het over? Het lijkt op het zelfde geblaat als http://leipepo.com/?p=10, eerlijk gezegd. Als je geen idee hebt waarom je meerdere lagen in een applicatie introduceert, zou ik je aanraden eerst daar naar te gaan kijken.

Je komt over als een kip zonder kop, niet wetende wat je wilt, waar je naar toe wilt en wat daarbij precies je boodschap is. Lees eens een catalogus van patterns voor enterprise applicatie architecturen door. Of lees wat of scalability of maintainability. Dat zijn de echte onderwerpen (in mijn ogen) als je praat over software engineering. De inside-out/outside-in werkt op een heel ander niveau, zoals RobIII ook al aangeeft.

Voor mijn werk onderhoud ik applicaties die meer dan 120.000.000 unieke hits per dag krijgen, dus mij hoef je niks wijs te maken over applicatie ontwikkeling. Frameworks zoals Zend e.d is grappig voor hobby projectjes, maar als je applicaties ontwikkeld waarbij als je 1mb per hit kan besparen(dus 117187 GiB in ons geval), 1 ms per request kan besparen, dat ook echt moet gebeuren willen je eind gebruikers er geen hinder van ondervinden, anders voelen ze zich geen superman, maar een oud opa-tje, en dat kost geld... een hoop geld..

Dat jullie vinden dat de outside-in theorie niet toepasbaar is op het ontwikkelen, is dat jullie visie, en daar heb ik respect voor, maar wat er gezegd is is dat het gaat om user experince, en om te denken dat de code daar niks mee te maken heb, vind ik erg kortzichtig, aangezien de snelheid een heel erg groot deel uit maakt van de expirince die de eindgebruiker ervan moet overtuigen dat zij superman zijn...

Je zegt dat ik klink als een kip zonder kop, maar tegelijkertijd tijd zeg je dat mijn verhaal hier hetzelfde klinkt als op me blog, dat lijkt mij behoorlijk consistent...

[Freeaqingme]

leipepo schreef op vrijdag 01 april 2011 @ 20:28:
Frameworks zoals Zend e.d is grappig voor hobby projectjes, maar [...]

Het mag 1 april zijn vandaag, je kan 't ook overdrijven.

[Voutloos]

leipepo schreef op vrijdag 01 april 2011 @ 16:49:
Vervolgens klagen de eind-gebruikers over snelheid problemen, waardoor de devvs een caching laag moeten introduceren, terwijl er als men er van uit ging van de eindgebruikers(outside-in) dit niet gebeurd was, of niet nodig was geweest...

Als je motto is het om het vooraf te doen, hoef je het niet achteraf te doen ja. Maar het moet alsnog gebeuren. En bovendien lijk je te suggereren dat je _altijd_ snelheids problemen zal krijgen met een framework...

... en ze pas echt toevoegen als ze echt noodzakelijk zijn voor je eindgebruikers(dus niet voor jezelf (inside-out))

Dergelijke implementatiedetails boeien echt totaal niet voor je gebruikers. Nog nimmer heeft een gebruiker/klant gezegd: "O, wat ben ik blij dat het gewoon een 1 grote functie is!" of "Oe, wat is dit toch allemaal overdreven geabstraheerd!"

Dit soort implementatiedetails zijn vooral interessant voor de partij die het implementeert. En dat is dus het allerbelangrijkste punt, en een punt dat je totaal mist: Dit soort backend beslissingen heeft invloed op ontwikkeltijd, doorlooptijd, herbruikbaarheid, learning curve, onderhoudbaarheid etc. etc. Ook al staat de gebruiker centraal in je proces heeft dat motto alsnog totaal niets nada noppes met deze backend beslissing te maken.

Er is niet per se een verband tussen de mate waarin je vanuit de eindgebruiker denkt en de keuze voor een of geen framework. .

wat ik zelf zou doen is een tmpfs aan maken, daar de bestanden in gooien, dan zorgt het os er voor dat het compleet vanuit de geheugen draait, waardoor je disk io in ieder geval niet meer de bottleneck is, en geen meerdere lagen introduceert...

Zie reactie 1, opcode cache is het magische woord in deze context. Nu wil je weer kosten wat het kost het wiel opnieuw uitvinden, maar dan zonder het cachen van opcodes, wat misschien wel de meest significante winst voor een PHP app kan zijn.

Tevens vind ik ook dat als je gediciplineerd een MVC pattern toepast, je geen framework nodig heb.

Het een sluit het ander niet uit. Netjes MVC betekent niet dat je per se alles zelf moet uitvinden. En ja, het betekent ook niet dat je per se dat je een framework nodig hebt of alles bij elkaar moet copy/pasten.

[drm]

Het een sluit het ander niet uit. Netjes MVC betekent niet dat je per se alles zelf moet uitvinden. En ja, het betekent ook niet dat je per se dat je een framework nodig hebt of alles bij elkaar moet copy/pasten.

offtopic:
Sterker nog, MVC hoeft niet eens object-georienteerd te zijn.