Files
@ 70e29dc91deb
Branch filter:
Location: kallithea/docs/usage/performance.rst - annotation
70e29dc91deb
2.8 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.
fa88997aa421 fa88997aa421 fa88997aa421 e73a69cb98dc fa88997aa421 fa88997aa421 e73a69cb98dc 5d12768a0aa1 5d12768a0aa1 5d12768a0aa1 5d12768a0aa1 e73a69cb98dc 5d12768a0aa1 5d12768a0aa1 5d12768a0aa1 4cd84f4f28fb 4cd84f4f28fb 5d12768a0aa1 fa88997aa421 e73a69cb98dc fa88997aa421 fa88997aa421 3b179f1ac3a2 fa88997aa421 3b179f1ac3a2 8b8edfc25856 3b179f1ac3a2 fa88997aa421 fa88997aa421 fa88997aa421 fa88997aa421 fa88997aa421 e73a69cb98dc 5d12768a0aa1 fa88997aa421 fa88997aa421 8b8edfc25856 fa88997aa421 fa88997aa421 fa88997aa421 fa88997aa421 8b8edfc25856 e73a69cb98dc fa88997aa421 4cd84f4f28fb e73a69cb98dc 4cd84f4f28fb 4cd84f4f28fb d79f3505549e 4cd84f4f28fb d79f3505549e 4cd84f4f28fb 4cd84f4f28fb 4cd84f4f28fb 4cd84f4f28fb e73a69cb98dc 4cd84f4f28fb 4cd84f4f28fb d79f3505549e 4cd84f4f28fb 4cd84f4f28fb 4cd84f4f28fb | .. _performance:
================================
Optimizing Kallithea Performance
================================
When serving large amount of big repositories Kallithea can start
performing slower than expected. Because of demanding nature of handling large
amount of data from version control systems here are some tips how to get
the best performance.
* Kallithea will perform better on machines with faster disks (SSD/SAN). It's
more important to have faster disk than faster CPU.
* Slowness on initial page can be easily fixed by grouping repositories, and/or
increasing cache size (see below), that includes using lightweight dashboard
option and vcs_full_cache setting in .ini file
Follow these few steps to improve performance of Kallithea system.
1. Increase cache
in the .ini file::
beaker.cache.sql_cache_long.expire=3600 <-- set this to higher number
This option affects the cache expiration time for main page. Having
few hundreds of repositories on main page can sometimes make the system
to behave slow when cache expires for all of them. Increasing `expire`
option to day (86400) or a week (604800) will improve general response
times for the main page. Kallithea has an intelligent cache expiration
system and it will expire cache for repositories that had been changed.
2. Switch from sqlite to postgres or mysql
sqlite is a good option when having small load on the system. But due to
locking issues with sqlite, it's not recommended to use it for larger
setup. Switching to mysql or postgres will result in a immediate
performance increase.
3. Scale Kallithea horizontally
Scaling horizontally can give huge performance increase when dealing with
large traffic (large amount of users, CI servers etc). Kallithea can be
scaled horizontally on one (recommended) or multiple machines. In order
to scale horizontally you need to do the following:
- each instance needs it's own .ini file and unique `instance_id` set in them
- each instance `data` storage needs to be configured to be stored on a
shared disk storage, preferably together with repositories. This `data`
dir contains template caches, sessions, whoosh index and it's used for
tasks locking (so it's safe across multiple instances). Set the
`cache_dir`, `index_dir`, `beaker.cache.data_dir`, `beaker.cache.lock_dir`
variables in each .ini file to shared location across Kallithea instances
- if celery is used each instance should run separate celery instance, but
the message broken should be common to all of them (ex one rabbitmq
shared server)
- load balance using round robin or ip hash, recommended is writing LB rules
that will separate regular user traffic from automated processes like CI
servers or build bots.
|