Files
@ 70e29dc91deb
Branch filter:
Location: kallithea/docs/usage/statistics.rst - annotation
70e29dc91deb
1.2 KiB
text/prs.fallenstein.rst
ini file: clarify that beaker.session.key should be unique
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
bbd499c7b55e bbd499c7b55e 17c9393e9645 bbd499c7b55e bbd499c7b55e bbd499c7b55e e73a69cb98dc 8af52e1224ff 03bbd33bc084 8af52e1224ff bbd499c7b55e bbd499c7b55e 9472a0150bf0 bbd499c7b55e 8af52e1224ff 8af52e1224ff 8af52e1224ff 8af52e1224ff e73a69cb98dc 8af52e1224ff bbd499c7b55e bbd499c7b55e bbd499c7b55e 9472a0150bf0 bbd499c7b55e e73a69cb98dc 8af52e1224ff 8af52e1224ff 8af52e1224ff bbd499c7b55e bbd499c7b55e 8af52e1224ff 8af52e1224ff | .. _statistics:
==========
Statistics
==========
The Kallithea statistics system makes heavy demands of the server resources, so
in order to keep a balance between usability and performance, the statistics are
cached inside db and are gathered incrementally. This is how Kallithea does
this:
With Celery disabled
--------------------
- On each first visit to the summary page a set of 250 commits are parsed and
updates statistics cache.
- This happens on each single visit to the statistics page until all commits are
fetched. Statistics are kept cached until additional commits are added to the
repository. In such a case Kallithea will only fetch the new commits when
updating it's cache.
With Celery enabled
-------------------
- On the first visit to the summary page Kallithea will create tasks that will
execute on celery workers. This task will gather all of the stats until all
commits are parsed, each task will parse 250 commits, and run the next task to
parse next 250 commits, until all of the commits are parsed.
.. note::
At any time you can disable statistics on each repository via the repository
edit form in the admin panel. To do this just uncheck the statistics checkbox.
|