If Chamilo need to cache things, whatever the functionality is implemented, you can't really use Chamilo on a shared host. Personally I think that it's not a big deal (VPS are not really more expensive that a shared host) so we can consider using extra software like Memcached or Redis and use cron to clean the cache or use Varnish to store the whole html page.
Regards, Goulwen ----------------------------------------------------- Twitter : http://twitter.com/nautilebleu/ Skype : nautilebleu Web : http://nautilebleu.tumblr.com/ 2011/4/27 <[email protected]>: > Send Dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.chamilo.org/listinfo/dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dev digest..." > > > Today's Topics: > > 1. Re: caching data in php (Nathalie Blocry) > 2. Re: caching data in php (Sven Vanpoucke) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Apr 2011 15:13:13 +0200 > From: Nathalie Blocry <[email protected]> > Subject: Re: [chamilo-dev] caching data in php > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Caching per run does not solve my problem at all since the menu is only > build once per run anyway. Keep in mind that the handbook-content-table > is also user-specific and not really static. I dont understand > "denormalizing your database layer and storing some of these values > locally in your application instead of recalculating them everytime". > How can I store things locally in the application between page requests? > Can you maybe give an example of what you mean? > > > I have no preference for serializing to a file or to the db, but > db-serialization will probably prove less of a challenge in > multiple-server set-ups. > > > In both cases the problem of cleaning up cached data that is no longer > in use is problematic if you cannot do it on the logout-event (because > it isn't performed by everybody) and you cannot do it with a cron-job > because people on shared hosting may not have access to that. > > With file-serialization you can check the date everytime you retrieve > the cached data and destroy it when it is too old, but what with cached > data that is never accessed again? When a user looks at a handbook once > and then never again, this file needs to be removed too. > > Nathalie > > > Op 04/27/2011 02:10 PM, Philippe Van Eerdenbrugghe schreef: >> I would personally go for a file cache because it's much more easy to >> purge. >> >> If the Caching engine is responsible to get any cached data, we can >> have it check how old it is and either return the old data or >> recompute and return the data. >> >> What do you think o that idea ? >> >> Systho >> >> Le 27/04/2011 14:02, Sven Vanpoucke a ?crit : >>> Triggering these actions on an event like a user logout isn't a very >>> good idea either. Because not many users actually use the logout >>> button. In fact, triggering this with any event, like for example >>> the login could make this event very slow... >>> >>> I am very much in favor of introducing caching into the code. But i'm >>> more the person who likes to cache the things for reuse in the same >>> run (like we already did with registrations, settings...). I don't >>> really like the idea that we start caching between multiple runs due >>> to the fact that it's much harder to debug these things. I'm much >>> more in favor to solve these performance issues by denormalizing your >>> database layer and storing some of these values locally in your >>> application instead of recalculating them everytime. >>> >>> Best regards >>> Sven >>> >>> Op 27/04/11 13:49, Laurent Opprecht schreef: >>>> I would rather go for serialize/unserialize as it is meant to store >>>> objects. >>>> >>>> As for file serialization this is certainly doable but I would make >>>> that just another implementation. In this case we have to ensure we >>>> use a shared cache if we use several application servers. >>>> >>>> I didn't realize that cron may not be available. A good point >>>> indeed. So in this case we can have a clean up script and trigger it >>>> on some recurring event - for example when the user logout. >>>> >>>> >>>> Le 27.04.2011 12:56, Philippe Van Eerdenbrugghe a ?crit : >>>>> If you go for cron, don't forget that chamilo should be usable on >>>>> mutalised hosting where cron is not available. What about file >>>>> serialization and var_export /__set_state() functions ? >>>>> >>>>> the mtime can be checked directly in php code >>>>> >>>>> Systho >>>>> >>>>> Le 27/04/2011 12:46, Laurent Opprecht a ?crit : >>>>>> I believe a DB implementation would be a good first move - at >>>>>> least we are sure it will be available :-). >>>>>> I would just ensure the implementation is compatible in term of >>>>>> interface with APC - which should be more or less a standard by now. >>>>>> I.e. have functions such as add($key, $value, $time_to_leave) etc >>>>>> I don't think we should clear the cache by logout. After all some >>>>>> caching may still be usefull after logout. Cron would be my favorite. >>>>>> >>>>>> Le 27.04.2011 11:29, Nathalie Blocry a ?crit : >>>>>>> I have made a wiki page on this subject: >>>>>>> http://support.chamilo.org/projects/chamilo-20/wiki/Caching >>>>>>> >>>>>>> I know striclty speaking this is a new feature but I am convinced we >>>>>>> really need some kind or caching before we can release the >>>>>>> handbook app. >>>>>>> >>>>>>> I could implement it for now just for the handbook, but if I am >>>>>>> making >>>>>>> the effort anyway I think it would be better to implement the >>>>>>> platform-wide classes right-away, no? >>>>>>> >>>>>>> So I propose making the Cache class and just doing one >>>>>>> implementation >>>>>>> for now. >>>>>>> Still not sure what this one implementation should be. >>>>>>> nobody has any experience with caching data/objects (not pages)? >>>>>>> >>>>>>> short-term serializing and storing in the database might be the best >>>>>>> default system? With some cron-script to periodically clean out the >>>>>>> table, because we can clean-up at logout, but not many users will >>>>>>> actualy do that I think (I never do ;-)) >>>>>>> >>>>>>> >>>>>>> Op 04/26/2011 01:32 PM, Hans De Bisschop schreef: >>>>>>>> That's the Chamilo 2.0 spirit *thumbs up* 8-) :-) >>>>>>>> >>>>>>>> Hans >>>>>>>> >>>>>>>> On 26/04/2011 12:42, Laurent Opprecht wrote: >>>>>>>>> We may abstract the caching mecanism. >>>>>>>>> >>>>>>>>> Something like: >>>>>>>>> >>>>>>>>> class Cache >>>>>>>>> class ApcCache extends Cache >>>>>>>>> class MemCache extends Cache >>>>>>>>> class DatabaseCache extends Cache >>>>>>>>> class SessionCache extends Cache >>>>>>>>> class EmptyCache extends Cache //Empty pattern >>>>>>>>> ... >>>>>>>>> >>>>>>>>> With a factory method inside the Cache class. If the cache >>>>>>>>> is not >>>>>>>>> available - because memcach is not installed for example - >>>>>>>>> then >>>>>>>>> we can return the Empty cache that does nothing or >>>>>>>>> defaults to >>>>>>>>> anoter implementation. >>>>>>>>> >>>>>>>>> That would make Chamilo independant from specific cache >>>>>>>>> implemenation >>>>>>>>> yet providing the service for those applications that need it. >>>>>>>>> >>>>>>>>> Le 26.04.2011 12:26, Sven Vanpoucke a ?crit : >>>>>>>>>> I would not use memcached or another tool for caching because >>>>>>>>>> this >>>>>>>>>> would mean that we would demand yet another package to be >>>>>>>>>> installed >>>>>>>>>> on the server before chamilo can be used. >>>>>>>>> -- >>>>>>>>> ____________________________________ >>>>>>>>> Meilleures salutations >>>>>>>>> >>>>>>>>> Laurent Opprecht >>>>>>>>> >>>>>>>>> chat:[email protected] >>>>>>>>> blog:http://ciel.unige.ch/ >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>>>> -- >>>>>>>> >>>>>>>> *Hans De Bisschop* >>>>>>>> Hoofddeskundige ICTO | Lead Developer Chamilo 2.0 >>>>>>>> Software Coordinator Chamilo Association >>>>>>>> Erasmushogeschool Brussel >>>>>>>> Nijverheidskaai 170 | B-1070 Brussel >>>>>>>> T 02 559 02 54 | i 254 >>>>>>>> [email protected] <mailto:[email protected]> | >>>>>>>> www.erasmushogeschool.be <http://www.erasmushogeschool.be/> >>>>>>>> >>>>>>>> Kom eens langs:www.erasmushogeschool.be/infodagen >>>>>>>> <http://www.erasmushogeschool.be/infodagen> >>>>>>>> of lees onze elektronische nieuwsbrief: ehbrief.ehb.be >>>>>>>> <http://ehbrief.ehb.be/> >>>>>>>> P Before printing, think about the environment >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>> >>>>>> >>>>>> -- >>>>>> ____________________________________ >>>>>> Meilleures salutations >>>>>> >>>>>> Laurent Opprecht >>>>>> >>>>>> chat: [email protected] >>>>>> blog: http://ciel.unige.ch/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://lists.chamilo.org/listinfo/dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://lists.chamilo.org/listinfo/dev >>>> >>> >>> >>> -- >>> Met vriendelijke groeten >>> >>> Sven Vanpoucke >>> Digitaal Leren >>> Directie Onderwijs >>> Hogeschool Gent >>> http://digitaal-leren.hogent.be/ >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://lists.chamilo.org/listinfo/dev >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.chamilo.org/listinfo/dev > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.chamilo.org/pipermail/dev/attachments/20110427/fdd4b223/attachment-0001.htm> > > ------------------------------ > > Message: 2 > Date: Wed, 27 Apr 2011 15:13:27 +0200 > From: Sven Vanpoucke <[email protected]> > Subject: Re: [chamilo-dev] caching data in php > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > We could have an extra administration option to deleted temporary files > / caching data. > > Sven > > Op 27/04/11 15:13, Nathalie Blocry schreef: >> >> Caching per run does not solve my problem at all since the menu is >> only build once per run anyway. Keep in mind that the >> handbook-content-table is also user-specific and not really static. I >> dont understand "denormalizing your database layer and storing some of >> these values locally in your application instead of recalculating them >> everytime". How can I store things locally in the application between >> page requests? Can you maybe give an example of what you mean? >> >> >> I have no preference for serializing to a file or to the db, but >> db-serialization will probably prove less of a challenge in >> multiple-server set-ups. >> >> >> In both cases the problem of cleaning up cached data that is no longer >> in use is problematic if you cannot do it on the logout-event (because >> it isn't performed by everybody) and you cannot do it with a cron-job >> because people on shared hosting may not have access to that. >> >> With file-serialization you can check the date everytime you retrieve >> the cached data and destroy it when it is too old, but what with >> cached data that is never accessed again? When a user looks at a >> handbook once and then never again, this file needs to be removed too. >> >> Nathalie >> >> >> Op 04/27/2011 02:10 PM, Philippe Van Eerdenbrugghe schreef: >>> I would personally go for a file cache because it's much more easy to >>> purge. >>> >>> If the Caching engine is responsible to get any cached data, we can >>> have it check how old it is and either return the old data or >>> recompute and return the data. >>> >>> What do you think o that idea ? >>> >>> Systho >>> >>> Le 27/04/2011 14:02, Sven Vanpoucke a ?crit : >>>> Triggering these actions on an event like a user logout isn't a very >>>> good idea either. Because not many users actually use the logout >>>> button. In fact, triggering this with any event, like for example >>>> the login could make this event very slow... >>>> >>>> I am very much in favor of introducing caching into the code. But >>>> i'm more the person who likes to cache the things for reuse in the >>>> same run (like we already did with registrations, settings...). I >>>> don't really like the idea that we start caching between multiple >>>> runs due to the fact that it's much harder to debug these things. >>>> I'm much more in favor to solve these performance issues by >>>> denormalizing your database layer and storing some of these values >>>> locally in your application instead of recalculating them everytime. >>>> >>>> Best regards >>>> Sven >>>> >>>> Op 27/04/11 13:49, Laurent Opprecht schreef: >>>>> I would rather go for serialize/unserialize as it is meant to store >>>>> objects. >>>>> >>>>> As for file serialization this is certainly doable but I would make >>>>> that just another implementation. In this case we have to ensure we >>>>> use a shared cache if we use several application servers. >>>>> >>>>> I didn't realize that cron may not be available. A good point >>>>> indeed. So in this case we can have a clean up script and trigger >>>>> it on some recurring event - for example when the user logout. >>>>> >>>>> >>>>> Le 27.04.2011 12:56, Philippe Van Eerdenbrugghe a ?crit : >>>>>> If you go for cron, don't forget that chamilo should be usable on >>>>>> mutalised hosting where cron is not available. What about file >>>>>> serialization and var_export /__set_state() functions ? >>>>>> >>>>>> the mtime can be checked directly in php code >>>>>> >>>>>> Systho >>>>>> >>>>>> Le 27/04/2011 12:46, Laurent Opprecht a ?crit : >>>>>>> I believe a DB implementation would be a good first move - at >>>>>>> least we are sure it will be available :-). >>>>>>> I would just ensure the implementation is compatible in term of >>>>>>> interface with APC - which should be more or less a standard by >>>>>>> now. >>>>>>> I.e. have functions such as add($key, $value, $time_to_leave) etc >>>>>>> I don't think we should clear the cache by logout. After all some >>>>>>> caching may still be usefull after logout. Cron would be my >>>>>>> favorite. >>>>>>> >>>>>>> Le 27.04.2011 11:29, Nathalie Blocry a ?crit : >>>>>>>> I have made a wiki page on this subject: >>>>>>>> http://support.chamilo.org/projects/chamilo-20/wiki/Caching >>>>>>>> >>>>>>>> I know striclty speaking this is a new feature but I am >>>>>>>> convinced we >>>>>>>> really need some kind or caching before we can release the >>>>>>>> handbook app. >>>>>>>> >>>>>>>> I could implement it for now just for the handbook, but if I am >>>>>>>> making >>>>>>>> the effort anyway I think it would be better to implement the >>>>>>>> platform-wide classes right-away, no? >>>>>>>> >>>>>>>> So I propose making the Cache class and just doing one >>>>>>>> implementation >>>>>>>> for now. >>>>>>>> Still not sure what this one implementation should be. >>>>>>>> nobody has any experience with caching data/objects (not pages)? >>>>>>>> >>>>>>>> short-term serializing and storing in the database might be the >>>>>>>> best >>>>>>>> default system? With some cron-script to periodically clean out the >>>>>>>> table, because we can clean-up at logout, but not many users will >>>>>>>> actualy do that I think (I never do ;-)) >>>>>>>> >>>>>>>> >>>>>>>> Op 04/26/2011 01:32 PM, Hans De Bisschop schreef: >>>>>>>>> That's the Chamilo 2.0 spirit *thumbs up* 8-) :-) >>>>>>>>> >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> On 26/04/2011 12:42, Laurent Opprecht wrote: >>>>>>>>>> We may abstract the caching mecanism. >>>>>>>>>> >>>>>>>>>> Something like: >>>>>>>>>> >>>>>>>>>> class Cache >>>>>>>>>> class ApcCache extends Cache >>>>>>>>>> class MemCache extends Cache >>>>>>>>>> class DatabaseCache extends Cache >>>>>>>>>> class SessionCache extends Cache >>>>>>>>>> class EmptyCache extends Cache //Empty pattern >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> With a factory method inside the Cache class. If the >>>>>>>>>> cache is not >>>>>>>>>> available - because memcach is not installed for example >>>>>>>>>> - then >>>>>>>>>> we can return the Empty cache that does nothing or >>>>>>>>>> defaults to >>>>>>>>>> anoter implementation. >>>>>>>>>> >>>>>>>>>> That would make Chamilo independant from specific cache >>>>>>>>>> implemenation >>>>>>>>>> yet providing the service for those applications that need it. >>>>>>>>>> >>>>>>>>>> Le 26.04.2011 12:26, Sven Vanpoucke a ?crit : >>>>>>>>>>> I would not use memcached or another tool for caching because >>>>>>>>>>> this >>>>>>>>>>> would mean that we would demand yet another package to be >>>>>>>>>>> installed >>>>>>>>>>> on the server before chamilo can be used. >>>>>>>>>> -- >>>>>>>>>> ____________________________________ >>>>>>>>>> Meilleures salutations >>>>>>>>>> >>>>>>>>>> Laurent Opprecht >>>>>>>>>> >>>>>>>>>> chat:[email protected] >>>>>>>>>> blog:http://ciel.unige.ch/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Hans De Bisschop* >>>>>>>>> Hoofddeskundige ICTO | Lead Developer Chamilo 2.0 >>>>>>>>> Software Coordinator Chamilo Association >>>>>>>>> Erasmushogeschool Brussel >>>>>>>>> Nijverheidskaai 170 | B-1070 Brussel >>>>>>>>> T 02 559 02 54 | i 254 >>>>>>>>> [email protected] <mailto:[email protected]> | >>>>>>>>> www.erasmushogeschool.be <http://www.erasmushogeschool.be/> >>>>>>>>> >>>>>>>>> Kom eens langs:www.erasmushogeschool.be/infodagen >>>>>>>>> <http://www.erasmushogeschool.be/infodagen> >>>>>>>>> of lees onze elektronische nieuwsbrief: ehbrief.ehb.be >>>>>>>>> <http://ehbrief.ehb.be/> >>>>>>>>> P Before printing, think about the environment >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ____________________________________ >>>>>>> Meilleures salutations >>>>>>> >>>>>>> Laurent Opprecht >>>>>>> >>>>>>> chat: [email protected] >>>>>>> blog: http://ciel.unige.ch/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://lists.chamilo.org/listinfo/dev >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://lists.chamilo.org/listinfo/dev >>>>> >>>> >>>> >>>> -- >>>> Met vriendelijke groeten >>>> >>>> Sven Vanpoucke >>>> Digitaal Leren >>>> Directie Onderwijs >>>> Hogeschool Gent >>>> http://digitaal-leren.hogent.be/ >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://lists.chamilo.org/listinfo/dev >>>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://lists.chamilo.org/listinfo/dev >>> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.chamilo.org/listinfo/dev >> > > > -- > Met vriendelijke groeten > > Sven Vanpoucke > Digitaal Leren > Directie Onderwijs > Hogeschool Gent > http://digitaal-leren.hogent.be/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.chamilo.org/pipermail/dev/attachments/20110427/4aab734f/attachment.htm> > > ------------------------------ > > _______________________________________________ > Dev mailing list > [email protected] > http://lists.chamilo.org/listinfo/dev > > > End of Dev Digest, Vol 15, Issue 51 > *********************************** > _______________________________________________ Dev mailing list [email protected] http://lists.chamilo.org/listinfo/dev
