performance.rst
56 lines
| 2.5 KiB
| text/x-rst
|
RstLexer
r2517 | .. _performance: | |||
================================ | ||||
|
r5413 | Optimizing Kallithea performance | ||
r2517 | ================================ | |||
|
r4955 | 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 | ||||
r2775 | the best performance. | |||
|
r5425 | * Kallithea is often I/O bound, and hence a fast disk (SSD/SAN) is | ||
usually more important than a fast CPU. | ||||
r2775 | ||||
|
r5425 | * Sluggish loading of the front page can easily be fixed by grouping repositories or by | ||
|
r4955 | increasing cache size (see below). This includes using the lightweight dashboard | ||
|
r5425 | option and ``vcs_full_cache`` setting in .ini file. | ||
r2775 | ||||
|
r4192 | Follow these few steps to improve performance of Kallithea system. | ||
r2517 | ||||
r2680 | 1. Increase cache | |||
r2517 | ||||
|
r5400 | Tweak beaker cache settings in the ini file. The actual effect of that | ||
|
r5399 | is questionable. | ||
r2517 | ||||
|
r5425 | 2. Switch from SQLite to PostgreSQL or MySQL | ||
r3224 | ||||
|
r5425 | 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 PostgreSQL will result in an immediate | ||||
|
r5060 | performance increase. A tool like SQLAlchemyGrate_ can be used for | ||
migrating to another database platform. | ||||
r3224 | ||||
|
r4192 | 3. Scale Kallithea horizontally | ||
r2517 | ||||
|
r5425 | Scaling horizontally can give huge performance benefits when dealing with | ||
large amounts of traffic (many users, CI servers, etc.). Kallithea can be | ||||
r3390 | scaled horizontally on one (recommended) or multiple machines. In order | |||
to scale horizontally you need to do the following: | ||||
r3413 | ||||
|
r4955 | - 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 | ||||
r3390 | that will separate regular user traffic from automated processes like CI | |||
servers or build bots. | ||||
|
r5060 | |||
|
r5433 | |||
|
r5060 | .. _SQLAlchemyGrate: https://github.com/shazow/sqlalchemygrate | ||