Files
@ 6257de126ec7
Branch filter:
Location: kallithea/docs/usage/performance.rst - annotation
6257de126ec7
2.5 KiB
text/prs.fallenstein.rst
docs: improve documentation of beaker session configuration
beaker.session.auto is dropped; it defaults to false and there is no reason to
ever set it true for Kallithea.
beaker.session.cookie_path and secure are dropped; like cookie_domain, they
should automatically be set to the right value.
* * *
beaker.session.cookie_expires MUST have the default value of True to provide the default value of 'browser session lifetime' when not enabling 'remember' in the login box. The cookie life is hardcoded to 365 days when remember is selected.
beaker.session.auto is dropped; it defaults to false and there is no reason to
ever set it true for Kallithea.
beaker.session.cookie_path and secure are dropped; like cookie_domain, they
should automatically be set to the right value.
* * *
beaker.session.cookie_expires MUST have the default value of True to provide the default value of 'browser session lifetime' when not enabling 'remember' in the login box. The cookie life is hardcoded to 365 days when remember is selected.
fa88997aa421 fa88997aa421 fa88997aa421 e73a69cb98dc fa88997aa421 fa88997aa421 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 5d12768a0aa1 5d12768a0aa1 e73a69cb98dc 4e6dfdb3fa01 5d12768a0aa1 5d12768a0aa1 4e6dfdb3fa01 4e6dfdb3fa01 5d12768a0aa1 fa88997aa421 e73a69cb98dc fa88997aa421 fa88997aa421 3b179f1ac3a2 fa88997aa421 6257de126ec7 4610a39d3be9 fa88997aa421 fa88997aa421 8b8edfc25856 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 778f7ae3b6eb 778f7ae3b6eb 8b8edfc25856 e73a69cb98dc fa88997aa421 4e6dfdb3fa01 e73a69cb98dc 4cd84f4f28fb 4cd84f4f28fb d79f3505549e 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4e6dfdb3fa01 4cd84f4f28fb 4cd84f4f28fb 778f7ae3b6eb 778f7ae3b6eb | .. _performance:
================================
Optimizing Kallithea Performance
================================
When serving a large amount of big repositories, Kallithea can start
performing slower than expected. Because of the demanding nature of handling large
amounts of data from version control systems, here are some tips on how to get
the best performance.
* Kallithea will perform better on machines with faster disks (SSD/SAN). It's
more important to have a faster disk than a faster CPU.
* Slowness on initial page can be easily fixed by grouping repositories, and/or
increasing cache size (see below). This includes using the lightweight dashboard
option and ``vcs_full_cache`` setting in .ini file
Follow these few steps to improve performance of Kallithea system.
1. Increase cache
Tweak beaker cache settings in the ini file. The actual effect of that
is questionable.
2. Switch from sqlite to postgres or mysql
sqlite is a good option when having a small load on the system. But due to
locking issues with sqlite, it is not recommended to use it for larger
deployments. Switching to mysql or postgres will result in an immediate
performance increase. A tool like SQLAlchemyGrate_ can be used for
migrating to another database platform.
3. Scale Kallithea horizontally
Scaling horizontally can give huge performance increases 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 its own .ini file and unique ``instance_id`` set.
- Each instance's ``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 is used for
task locking (so it is safe across multiple instances). Set the
``cache_dir``, ``index_dir``, ``beaker.cache.data_dir``, ``beaker.cache.lock_dir``
variables in each .ini file to a shared location across Kallithea instances
- If celery is used each instance should run a separate Celery instance, but
the message broker should be common to all of them (e.g., one
shared RabbitMQ 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.
.. _SQLAlchemyGrate: https://github.com/shazow/sqlalchemygrate
|