On a related notes, we've discovered issues a few months ago on our
XWiki 3.5 where the temp files were on some default temporary directory
(as is described wishable here by Denis). Curriki servers are typically
long-lived (a few weeks) and thus the OS maintenance can kick in and,
that's exactly what happened: the temporary directory (I think it was
somewhere on /var/tmp) got emptied after a while and that lead the
/download/ handler to raise an exception because it did not expect the
temp files to be deleted.
We managed to find out why it was deleted and neutralized that.
So, Denis, I think it is rather a good idea to have cached files in a
non-temporary directory if you want to avoid such conflicts.
paul
On 13/02/15 19:39, Denis Gervalle wrote:
Hi Guillaume,
1) -1, this break the FHS which definitely separate caches from permanent
data, and for a couple of good reason, you may want to put them on
different partition, using faster disk, or even in memory disk. So I do not
find very clever to put all cache files into the permanent directory. What
would be the purpose of a temporary directory if it was not for that
purpose.
2) +1, but with some way to force the purge, so annoying problem still get
a solution
3) +1, it would be very helpful to have faster startup when testing. I
would not put the file into the cache in the distribution, but in a skin
folder or something, and it could simply copy the file in place of
generating it for the default skin. So this could work on any distribution,
and it could also solve your temporary folder issue.
wdyt ?
On Thu, Feb 12, 2015 at 5:55 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi.
Currently, XWiki is quite long to start, and this is mainly because of the
LESS compiler which generates the CSS file of the skin.
Fortunately, we cache the results of the compilation in the LESS cache,
which is stored in the file-system (this is important).
Some actions can be done to make the launch quicker:
1 - Not purge the cache at startup.
The idea is to keep the cache of the previous launch of XWiki, so LESS
would have nothing to compile anymore. This does not solve the first launch
issue, but it is a great progress anyway. The disadvantage of this is that
restarting XWiki will not solve any issue related to a bad cached file (ex:
a buggy CSS file stored in the cache will still be there after a restart.
The only way to fix this is to re-save the buggy LESS resource).
Note that this behaviour can easily be changed by modifying a config file:
http://extensions.xwiki.org/xwiki/bin/view/Extension/LESS+Module#HCacheStra…
2 - During the build of XE, run an integration test that performs a simple
view request to XWiki in order to make the LESS compiler builds the CSS
file and pushes it into the cache. After the integration test, we just copy
the generated LESS cache file into the Jetty/HSQLDB distribution, and so
when you launch XWiki from this distribution, you use the pre-generated
cache.
Of course it could only work for our Jetty distributions that users test
locally. It will not solve the issue on production servers. But it is
already good that a user have a good impression by starting XWiki quickly
on her computer.
I have made a proof of concept on a branch [1] and the thing is working
well. The first request to XWiki is really faster.
The only blocking point I have now is that the current cache directory is
currently configured to be the temporary directory. Instead, I need to use
a directory from the distribution (where I can put my pre-generated cache
files). I have solved this locally by setting an absolute path to my "data"
folder [2], but it is not clean.
Thomas suggested me to configure all the caches to use the "permdir"
directory, which actually is the "data" directory in the case of our jetty
distributions, and so it does the job.
So the vote is for the following proposal:
1 - move the cache files to permdir
2 - do not purge the LESS cache at startup (by default)
3 - add a new module that pre-generate the LESS cache file to make the
first XWiki launch faster
Here is my +1.
Thanks,
[1]
https://github.com/xwiki/xwiki-enterprise/compare/feature-datalesscache
[2]
http://jira.xwiki.org/browse/XWIKI-10879?focusedCommentId=85369&page=co…
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the
XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs