Show More
@@ -13,7 +13,8 b' the best performance.' | |||
|
13 | 13 | more important to have faster disk than faster CPU. |
|
14 | 14 | |
|
15 | 15 | * Slowness on initial page can be easily fixed by grouping repositories, and/or |
|
16 | increasing cache size (see below) | |
|
16 | increasing cache size (see below), that includes using lightweight dashboard | |
|
17 | option and vcs_full_cache setting in .ini file | |
|
17 | 18 | |
|
18 | 19 | |
|
19 | 20 | Follow these few steps to improve performance of RhodeCode system. |
@@ -41,10 +42,23 b' 2. Switch from sqlite to postgres or mys' | |||
|
41 | 42 | |
|
42 | 43 | 3. Scale RhodeCode horizontally |
|
43 | 44 | |
|
44 | - running two or more instances on the same server can speed up things a lot | |
|
45 | - load balance using round robin or ip hash | |
|
46 | - you need to handle consistent user session storage by switching to | |
|
47 | db sessions, client side sessions or sharing session data folder across | |
|
48 | instances. See http://beaker.readthedocs.org/ docs for details. | |
|
49 |
|
|
|
50 | `instance_id` set in them | |
|
45 | Scaling horizontally can give huge performance increase when dealing with | |
|
46 | large traffic (large amount of users, CI servers etc). RhodeCode can be | |
|
47 | scaled horizontally on one (recommended) or multiple machines. In order | |
|
48 | to scale horizontally you need to do the following: | |
|
49 | ||
|
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 | |
|
52 | shared disk storage, preferably together with repositories. This `data` | |
|
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 | |
|
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 | |
|
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 | |
|
59 | shared server) | |
|
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 | |
|
62 | servers or build bots. | |
|
63 | ||
|
64 |
General Comments 0
You need to be logged in to leave comments.
Login now