![]() |
|
Observing the inner workings of the server
The cache
The cache enables the server to store HTML fragments to avoid to recalculate everything when it can be avoided. Recalculating has a high cost and should be avoided whenever possible.
Two types of fragments are cached: compete HTML pages and boxes (little bits of HTML which can be inserted in a page). These two aspects are separated.
$ mkdir dacache $ mkdir dacache/boxes dacache/pages |
Apache maintains the cache. It needs to have the correct permissions to read and write in the cachce directory. For now, we give generous permissions. We will adjust later.
$ chmod o+rwx dacache/boxes/ dacache/pages/ |
We have to add our directories in config.site
$ grep cache daCode/config.site $this->cachedir = "/home/dacode/dacache/boxes/"; $this->htmldir = "/home/dacode/dacache/pages/"; $ cd daCode; scripts/dacodeconfig -a configure |
Now, the cache should be working. If you call your site, files will appear in your cache directories. No specific maintainance needed.
The filenames look like that:
$ ls dacache/* dacache/boxes: backends_agenda--.,0.html dacode_dacode--,0.html.1.0. backends_kernel--.,0.html sidebox_topics--,0.html.1.0. dacache/pages: index,0,1,0.html |
The header (backend_agenda) tells which script has generated this file. The suffixes, separated by comas or points, represent a user's profile.
-
An anonymous user
-
A user prefering the Slashdot theme
-
a user prefering the Default theme and somehing else (TODO)
Two remarks:
-
The more options the users profiles will have, the more files the cache will have to create (is it still correct?!)
-
You may find it easier to consider that the users profiles are a part of the daCode database stored in cookies by the browser, and which is accessed by daCode through the 'Session' class. This is mainly false, but it may be useful to understand the way the server works, with a high level of abstraction.