Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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

Pagina: 1
Acties:

  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
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

B


  • Voutloos
  • Registratie: januari 2002
  • Niet online
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?

Talkin.nl daily photoblog


  • -DarkShadow-
  • Registratie: december 2001
  • Niet online
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?

Wij zoeken een PHP developer
Soldeerstations
Labvoeding


  • drm
  • Registratie: februari 2001
  • Laatst online: 13-09 20:19

drm

f0pc0dert

quote:
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.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • Voutloos
  • Registratie: januari 2002
  • Niet online
Overigens is het dusdanig vaak nuttig dat het compleet stupide, achterlijk en enorm 1995 is dat het niet standaard aan staat / ingebakken is. ;)

Voutloos wijzigde deze reactie 28-03-2011 23:20 (5%)

Talkin.nl daily photoblog


  • kwaakvaak_v2
  • Registratie: juni 2009
  • Laatst online: 18-10 22:14
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 ;)

Redelijk wat fruit speelgoed, paar vps'en en nog wat wat andere zut.


  • ZpAz
  • Registratie: september 2005
  • Laatst online: 18-10 22:50
Iets met loose coupling en high cohesion.

"People say nothing is impossible, yet I do nothing every day." - Pooh


  • Cartman!
  • Registratie: april 2000
  • Niet online
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
  • Registratie: maart 2003
  • Niet online
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
  • Registratie: juni 2009
  • Laatst online: 18-10 22:14
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 ;))
quote:
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 :)

Redelijk wat fruit speelgoed, paar vps'en en nog wat wat andere zut.


  • FragFrog
  • Registratie: september 2001
  • Laatst online: 01:17
quote:
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).

[ Site ]


  • Cartman!
  • Registratie: april 2000
  • Niet online
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 :)
quote:
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.

Cartman! wijzigde deze reactie 29-03-2011 10:52 (55%)


  • FragFrog
  • Registratie: september 2001
  • Laatst online: 01:17
quote:
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 :+

FragFrog wijzigde deze reactie 29-03-2011 11:03 (11%)

[ Site ]


  • Cartman!
  • Registratie: april 2000
  • Niet online
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
  • Registratie: maart 2003
  • Niet online
quote:
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).
quote:
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
  • Registratie: oktober 2004
  • Laatst online: 18-10 22:57
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!
  • Registratie: april 2000
  • Niet online
quote:
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 :)

  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
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?

klandermans wijzigde deze reactie 29-03-2011 12:04 (17%)

B


  • Cartman!
  • Registratie: april 2000
  • Niet online
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
  • Registratie: oktober 2004
  • Laatst online: 18-10 22:57
quote:
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
  • Registratie: oktober 2003
  • Laatst online: 21-03 11:04
Let je er wel op dat je geen forwards etc. doet? Dan wordt namelijk de hele request chain opnieuw opgestart.

  • drm
  • Registratie: februari 2001
  • Laatst online: 13-09 20:19

drm

f0pc0dert

quote:
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.
quote:
klandermans:
Wat zou je dan nog moeten gaan cachen?
Weet je wel wat bedoeld wordt met een opcode of bytecode cache?

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]


  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
quote:
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.

B


  • Freeaqingme
  • Registratie: april 2006
  • Nu online
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?

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • ReenL
  • Registratie: augustus 2010
  • Laatst online: 22-03-2015
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
  • Registratie: juni 2008
  • Laatst online: 18-10 10:53
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...

  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
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?

B


  • storeman
  • Registratie: april 2004
  • Laatst online: 07:43
@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.

storeman wijzigde deze reactie 29-03-2011 22:49 (25%)

"Chaos kan niet uit de hand lopen"


  • RobIII
  • Registratie: december 2001
  • Laatst online: 14:09

RobIII

Moderator Devschuur®

^ Romeinse 3 ja!

quote:
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 ;)

Flat earth is not theory, it is a diagnosis.

Over mij


  • Freeaqingme
  • Registratie: april 2006
  • Nu online
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.
quote:
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.
quote:
@ 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.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
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.

B


  • Cartman!
  • Registratie: april 2000
  • Niet online
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
  • Registratie: april 2006
  • Nu online
Ik zou het sowieso benchmarken. Meten = weten.

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • klandermans
  • Registratie: januari 2005
  • Laatst online: 31-07-2011
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.

B


  • Freeaqingme
  • Registratie: april 2006
  • Nu online
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...

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • ameesters
  • Registratie: juni 2008
  • Laatst online: 18-10 10:53
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
  • Registratie: maart 2003
  • Niet online
^^ 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.

  • CIStem
  • Registratie: augustus 2004
  • Laatst online: 17-10 23:04
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
  • Registratie: juni 2008
  • Laatst online: 18-10 10:53
quote:
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
  • Registratie: april 2006
  • Nu online
quote:
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. _/-\o_

No trees were harmed in creating this message. However, a large number of electrons were terribly inconvenienced.


  • Voutloos
  • Registratie: januari 2002
  • Niet online
quote:
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. :z En bovendien lijk je te suggereren dat je _altijd_ snelheids problemen zal krijgen met een framework...
quote:
... 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. .
quote:
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. ;)
quote:
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.

Talkin.nl daily photoblog


Acties:
  • 0Henk 'm!

  • drm
  • Registratie: februari 2001
  • Laatst online: 13-09 20:19

drm

f0pc0dert

quote:
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.

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz
[ melp.nl | twitter ]

Pagina: 1


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True