| 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. |
|---|