Xavier, there is something called premature optimization. I'd worry about it not too much and deal with it when the need arises. Of course caching large result sets/expensive queries can be a performance booster but a cache always has the trade-off of being not realtime. :)
I'd probably always cache the parsed .ini file, but aside from that I don't know your app and IMO there is not much to generalize about optimization. Using xdebug can reveal bottlenecks, but also keep in mind the other parts - webserver, database etc.. Till On 10/12/07, Xavier Vidal <[EMAIL PROTECTED]> wrote: > Hi > > Apart from using opcode cache like APC, eAccelerator... > > Which objects/components should you recommend to be cached to achieve better > perfomance? > > As you said, .ini files is an example. I'm caching database tables metadata > too, so, anything more that could be interesting to cache, apart from > resultsets from database queries? > > thanks > > > -----Mensaje original----- > De: till [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 12 de octubre de 2007 10:41 > Para: Dennis Fogg > CC: fw-general@lists.zend.com > Asunto: Re: [fw-general] ZF performance advice > > Hi > > On 10/12/07, Dennis Fogg <[EMAIL PROTECTED]> wrote: > > (...) > > -use eAccelerator as opcode cache > > I am sure you probably had no issues yet, but I ran into plenty of > weirdness with eAccelerator and Zend Framework, but I had no issues > with APC. > > > My ZF infrastructure currently does the following: > > -sets up Zend_Loader > > -sets up registry, config_ini, Zend_translate, Zend_log > > Parsing .ini files is always a performance issue. Which is why you > should cache it. :) > > > (...) > > Over 20+ runs, I got the following data: > > > > .57 sec (44%) for db connection even though it's persistent connection > > Just curious - but do they really work? I know that supposedly a > persistant connection is re-used and you save the overhead of > establishing the connection etc. - but have you check if it actually > works? > > > (...) > > Till
