Mercurial > kallithea

comparison docs/usage/performance.rst @ 4192:e73a69cb98dc kallithea-2.2.5-rebrand

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Rename some strings examples and commands in documentation
author Bradley M. Kuhn <bkuhn@sfconservancy.org>
date Wed, 02 Jul 2014 19:04:41 -0400
parents d79f3505549e
children 4e6dfdb3fa01
comparison
equal deleted inserted replaced
4191:9171248beae5 4192:e73a69cb98dc
1 .. _performance: 1 .. _performance:
2 2
3 ================================ 3 ================================
4 Optimizing RhodeCode Performance 4 Optimizing Kallithea Performance
5 ================================ 5 ================================
6 6
7 When serving large amount of big repositories RhodeCode can start 7 When serving large amount of big repositories Kallithea can start
8 performing slower than expected. Because of demanding nature of handling large 8 performing slower than expected. Because of demanding nature of handling large
9 amount of data from version control systems here are some tips how to get 9 amount of data from version control systems here are some tips how to get
10 the best performance. 10 the best performance.
11 11
12 * RhodeCode will perform better on machines with faster disks (SSD/SAN). It's 12 * Kallithea will perform better on machines with faster disks (SSD/SAN). It's
13 more important to have faster disk than faster CPU. 13 more important to have faster disk than faster CPU.
14 14
15 * Slowness on initial page can be easily fixed by grouping repositories, and/or 15 * Slowness on initial page can be easily fixed by grouping repositories, and/or
16 increasing cache size (see below), that includes using lightweight dashboard 16 increasing cache size (see below), that includes using lightweight dashboard
17 option and vcs_full_cache setting in .ini file 17 option and vcs_full_cache setting in .ini file
18 18
19 19
20 Follow these few steps to improve performance of RhodeCode system. 20 Follow these few steps to improve performance of Kallithea system.
21 21
22 22
23 1. Increase cache 23 1. Increase cache
24 24
25 in the .ini file:: 25 in the .ini file::
28 28
29 This option affects the cache expiration time for main page. Having 29 This option affects the cache expiration time for main page. Having
30 few hundreds of repositories on main page can sometimes make the system 30 few hundreds of repositories on main page can sometimes make the system
31 to behave slow when cache expires for all of them. Increasing `expire` 31 to behave slow when cache expires for all of them. Increasing `expire`
32 option to day (86400) or a week (604800) will improve general response 32 option to day (86400) or a week (604800) will improve general response
33 times for the main page. RhodeCode has an intelligent cache expiration 33 times for the main page. Kallithea has an intelligent cache expiration
34 system and it will expire cache for repositories that had been changed. 34 system and it will expire cache for repositories that had been changed.
35 35
36 2. Switch from sqlite to postgres or mysql 36 2. Switch from sqlite to postgres or mysql
37 37
38 sqlite is a good option when having small load on the system. But due to 38 sqlite is a good option when having small load on the system. But due to
39 locking issues with sqlite, it's not recommended to use it for larger 39 locking issues with sqlite, it's not recommended to use it for larger
40 setup. Switching to mysql or postgres will result in a immediate 40 setup. Switching to mysql or postgres will result in a immediate
41 performance increase. 41 performance increase.
42 42
43 3. Scale RhodeCode horizontally 43 3. Scale Kallithea horizontally
44 44
45 Scaling horizontally can give huge performance increase when dealing with 45 Scaling horizontally can give huge performance increase when dealing with
46 large traffic (large amount of users, CI servers etc). RhodeCode can be 46 large traffic (large amount of users, CI servers etc). Kallithea can be
47 scaled horizontally on one (recommended) or multiple machines. In order 47 scaled horizontally on one (recommended) or multiple machines. In order
48 to scale horizontally you need to do the following: 48 to scale horizontally you need to do the following:
49 49
50 - each instance needs it's own .ini file and unique `instance_id` set in them 50 - each instance needs it's own .ini file and unique `instance_id` set in them
51 - each instance `data` storage needs to be configured to be stored on a 51 - each instance `data` storage needs to be configured to be stored on a
52 shared disk storage, preferably together with repositories. This `data` 52 shared disk storage, preferably together with repositories. This `data`
53 dir contains template caches, sessions, whoosh index and it's used for 53 dir contains template caches, sessions, whoosh index and it's used for
54 tasks locking (so it's safe across multiple instances). Set the 54 tasks locking (so it's safe across multiple instances). Set the
55 `cache_dir`, `index_dir`, `beaker.cache.data_dir`, `beaker.cache.lock_dir` 55 `cache_dir`, `index_dir`, `beaker.cache.data_dir`, `beaker.cache.lock_dir`
56 variables in each .ini file to shared location across RhodeCode instances 56 variables in each .ini file to shared location across Kallithea instances
57 - if celery is used each instance should run separate celery instance, but 57 - if celery is used each instance should run separate celery instance, but
58 the message broken should be common to all of them (ex one rabbitmq 58 the message broken should be common to all of them (ex one rabbitmq
59 shared server) 59 shared server)
60 - load balance using round robin or ip hash, recommended is writing LB rules 60 - load balance using round robin or ip hash, recommended is writing LB rules
61 that will separate regular user traffic from automated processes like CI 61 that will separate regular user traffic from automated processes like CI