root/cherokee/trunk/doc/cookbook_optimizations.txt

Revision 2466, 5.4 kB (checked in by taher, 1 week ago)

--

Line 
1 == link:index.html[Index] -> link:cookbook.html[Cookbook]
2
3 Cookbook: Optimizing Cherokee
4 -----------------------------
5
6 Cherokee's default parameters are suitable for most cases. However,
7 there are a number of things that can be tweaked in order to improve
8 the behavior of Cherokee under special circumstances.
9
10 [[compiled]]
11 Compiled capabilities
12 ~~~~~~~~~~~~~~~~~~~~~
13
14 First of all you should check the capabilities that have been built
15 into your specific Cherokee build. This can be done by:
16
17 ----
18 $ cherokee -i
19 Compilation
20  Version: 0.11.0
21
22 [...]
23
24 Support
25  IPv6: yes
26  OpenSSL: no
27  Pthreads: yes
28  Tracing: yes
29  sendfile(): yes
30  syslog(): yes
31  Polling methods: select poll epoll
32 ----
33
34 The last section is interesting. If you see that any siginficant
35 capability supported by your platform is missing, you should really
36 build another binary or check if something is wrong with your
37 system. Note that not every single capability is present in every
38 platform. For instance, `epoll` is a polling method specific to Linux
39 platforms, and its abscence from any non-Linux system is perfectly
40 normal. It is inherently more efficient than the other methods
41 available on Linux. For BSD based platforms `kqueue` is also a great
42 improvement over the most standard `poll`. This is the standard POSIX
43 conformant system call, and will only be available on systems that
44 follow the POSIX standard. From the list above, the capabilities that
45 have a dramatic impact in the speed of Cherokee are the polling
46 methods, the existence of sendfile() and the Pthreads support.
47
48
49 [[tweaks]]
50 Tweaks
51 ~~~~~~
52
53 There is no general recomendation that is the best for everybody. In
54 general Cherokee's default values try to offer a good compromise
55 between resources and performance, but for specific cases you will be
56 able to tweak somethings that may (or may not) improve the overall
57 performance. Some of the things to keep in mind are mentioned here.
58
59 Encoding::
60 As it is explained in the link:modules_encoders.html[Encoders']
61 documentation, compressing the information to be sent makes a lot of
62 sense for specific file types. It's Not that much processing power is
63 used to compress a text file, for instance, and hardware is cheaper
64 than bandwidth, so you should encode files whenever it makes sense.
65
66 Handler specific::
67 * *CGI, SCGI, FastCGI*: link:other_goodies.html#x-sendfile[X-Sendfile]
68   support can be enabled or disabled. If you know what this is, you
69   will know how X-Sendfile improves performance by assigning the task
70   of serving files to the web server while leaving the backend
71   application to run free without waiting for the task to end. This
72   gives you extra performance at no cost, but of course your
73   application must specifically make use of this feature.
74 +
75 * *Static Content*: IO cache is a caching mechanism that dramatically
76  improves performance serving files. The caching algorithm is very
77  efficient and assures that a file will be immediately served while it
78  remains cached. The usage of IO cache is absolutely recommended in
79  all cases except when the contents of the files are changed
80  frequently. Note that the global _IO Cache_ setting from the
81  _Advanced_ section (see bellow) must be enabled for each individual
82  handler's setting to be taken into account.
83
84 General::
85 +
86 * *Timeout*: The lower your timeout interval is, the faster you will
87   free up resources at the cost of cancelling viable but slow
88   connections.
89 +
90 * *Keep alive*: This setting dramatically affects the speed at which
91   repeated connections are served to the same client. This is
92   especially noticeable when an asyncrhonous application is used. The
93   trade off is that, since connections are kept open more time, less
94   connections remain available for other clients in any given
95   moment. Cherokee does a pretty good job at reclaiming unused open
96   connections, especially when the number of connections approaches
97   the limit imposed to the system, but any way you should keep in mind
98   this.
99
100 Advanced::
101 +
102 * *Threads*: The default value is chosen so that it is more than enough
103   to saturate the processors. You will probably not get much out of
104   this setting, since a higher value will not produce better results
105   and a lower one will simply increase the amount of unused processor
106   power.
107 +
108 * *File descriptors*: By deffinition, the higher this limit is, the
109   less efficient will your system be in relative terms. However, it
110   is understood that if you are tweaking this value is because you
111   need to, that is, you have a very high load site. In these cases
112   increasing the file descriptors' limit makes sense because the
113   higher this limit is, the more connections Cherokee will be able to
114   handle. By default Cherokee does not touch this value and it uses
115   the one specified by your system.
116 +
117 * *IO Cache*: This setting allows to enable or diasable server-wide
118   the content caching. If disabled, the _IO Cache_ settings of the
119   static content handlers will also be disabled, no matter what
120   behavior is desired in their specific configuration. This global
121   setting is essential if you are trying to debug a cache-related
122   bug in your server's configuration.
123
124 [[trace]]
125 Debug: Disable TRACE
126 ~~~~~~~~~~~~~~~~~~~~
127 When compiled with debugging support, Cherokee's performance is
128 heavily penalized. Being able to trace the state of the web server at
129 a very low level is quite useful when you have to fine tune your
130 infrastructure, but once it is done you should disable this feature.
131 A production environment deserves only the finest tuned binaries.
Note: See TracBrowser for help on using the browser.