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:laurent.oppre...@gmail.com
blog:http://ciel.unige.ch/
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
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
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
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
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
--
____________________________________
Meilleures salutations
Laurent Opprecht
chat: laurent.oppre...@gmail.com
blog: http://ciel.unige.ch/
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
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
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
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
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
