Create a small caching layer in PHP « Topincs Issues

Issue description

Some resources rarley change. A subject page is generated dynamically every time although it does not change so frequently. Same goes for a feed. It is necessary to create a small caching mechanism in PHP, which avoids the dynamic generation of pages.

Comment

[http://pear.php.net/package/Cache_Lite, Cache Lite] makes a good impression. After some central coding i was possible to avoid recreating large pages. The system would affect the resource definition and would cache entries depending on the query string. Additionally it would be necessary to make the system sensitive to the language the resource is delivered and also to the host, since the base is set in every page.

The general idea is to keep the cache simple for now, because it is very difficult to decide which update affects which resource. The simple principle for the moment is: the whole cache of a store is emptied on any POST, PUT, or DELETE to the store. Very simple.

The current solution system has the following features: * a store cache can be easily put in effect for a class of resources * a store cache can be made sensitive to varying representations of one resource * a store cache is emptied when a PUT, POST or DELETE to the store is received * a store cache can be cleared manually via the command line very easily by removing the directory below tmp/cache_lite * a store cache can be reset via the browser by calling admin/.clear-cache

This simple solution yields quite impressive results. With an active store cache 50 identical requests take 4.6 seconds. Without the cache they take 82 seconds!

Planned for version

Topincs 3.3.0 (Product version)

Caused

Configuration of the base dir of the cache (Enhancement)

Cache does not vary by method (Bug)

Realized through

Work session 11 (Work session)

Work session 16 (Work session)

Work session 17 (Work session)

Work session 18 (Work session)

Work session 19 (Work session)

Affects

Topincs Server (Component)

Reporting date

2009-07-10+02:00

Reported by

Robert Cerny (Person)

Resolving date

2009-07-14+02:00

Resolved by