Subsections
So there you are, with a nice big website you've spent weeks working on. And it's finally ready for the world to use it !
But you still have to decide how you will deploy it, which means: how will you set it up on the production
machine(s).
When you are developing your website, you're usually the only one (maybe with a few other developers) accessing the website,
so it doesn't need to be fast and robust. But on the production website, many people (if you're lucky) will access your
website. This means that you have to choose the proper CherryPy configuration in order to provide a fast/reliable service to
your users.
Criteria to help you choose your configuration include:
- What does you hosting provider let you do ? If you're on a shared machine, you might not be able to do what you want.
For instance, you may only be able to use CGI, and your hosting provider may only provide virtual hosting, behind Apache.
- How much traffic do you plan to get ? Do you plan to have only a few hundreds users per day or several tens of thousands ?
- How many machines/processors do you have ? (ie: how much money do you have) If you plan to have a lot of traffic,
then you might have to use several machines/processors (which means higher cost).
- Will there be a webmaster looking after the website ? If you don't have anyone looking after the website at all
time, you might want the website to restart automatically in case of a crash.
Note that there is a HowTo called "Sample deployment configuration for a
real-world website" that shows a full sample configuration that is
recommended for most websites.
The first decision to make is whether to use the CherryPy HTTP server directly or behind another webserver like Apache.
Here is a list of advantages for each method:
- Is faster and uses less ressources (no Apache processes and no need to talk between Apache and CherryPy)
- Is easier to set up
- Might be faster for serving static content (like images)
- Hosting provider might force you to use Apache
Once you've decided if you wanted to use CherryPy directly or behind another webserver, you still have to decide among
several configurations...
The following subsections show you what the different options are and what the advantages/drawbacks are:
Explaination: This means that the CherryPy HTTP server will run in one single thread/process. While
it is handling a request, no other request can connect to it during that time.
Advantages:
- Fast for each request (no need to create a thread/process for each request)
Drawbacks:
- Cannot handle concurrent requests
Conclusion: This method is the default configuration and it works fine for development, but it should be banned
for production if you might have several users accessing your website at the same time.
Explaination: This means that the CherryPy HTTP server will create a new process to handle each request.
After the response is sent back, the process is destroyed.
Advantages:
- Can handle multiple requests at a time
- On a multiprocessor machine, a forking server will take advantage of the several processors
Drawbacks:
- Might be expansive to create a new process for each request (especially if requests come in very fast)
- Forking doesn't work on Windows
- Cannot easily use sessions as session data cannot be easily shared among processes
Conclusion: This method can be used on non-Windows machines if the website's traffic isn't too high.
Explaination: This means that the CherryPy HTTP server will create a new thread to handle each request.
After the response is sent back, the thread is destroyed.
Advantages:
- Can handle multiple requests at a time
- Works on all platforms (including Windows)
Drawbacks:
- Might be expansive to create a new thread for each request (although less expensive than processes),
especially if requests come in very fast
- On a multiprocessor machine, a threading server will not take advantage of the several processors (due to the Python
global interpreter lock)
Conclusion: This method can be used if the website's traffic isn't too high.
Explaination: This means that the CherryPy HTTP server will create a fixed number of processes at startup, and
these processes will remain all the time. If one process if busy handling a request and another request comes in, then the
next process will step up and handle it.
Advantages:
- Can handle multiple requests at a time
- Fast because we don't need to create a thread or process for each request
- Takes advantage of multi-processor machines
Drawbacks:
- Doesn't work on Windows
- Cannot easily use sessions as session data cannot be easily shared among processes
Conclusion: This method works well on non-Windows machines, as long as you don't have hundreds of concurrent users.
Explaination: This means that the CherryPy HTTP server will create a fixed number of threads at startup, and
these threads will remain all the time. If one thread if busy handling a request and another request comes in, then the
next thread will step up and handle it.
Advantages:
- Can handle multiple requests at a time
- Fast because we don't need to create a thread or process for each request
Drawbacks:
- Doesn't take advantage of multi-processor machines.
- Number of threads doesn't increase if we have more concurrent users.
Conclusion: This method works very well and it is the recommended set-up in many cases (as long as you don't have hundreds of concurrent users).
If you really have a lot of traffic and the previous methods are not enough or you can not use them (if you're on
Windows for instance), then you can use generic load-balancing. There is a HowTo in the documentation about it.
All the configurations described in the previous section are also available when deploying CherryPy behind another webserver.
The third-party webserver will generally be multi-threaded or multi-processes. There is a HowTo in the
documentation that explains how to set this up.
Here is the list of the configuration file options that are used to specify how the CherryPy server will be deployed. All
these options are used within the [server] section of the configuration file (cf Chapter "Configuring CherryPy").
- socketPort: This indicates which port the server should listen to. Example:
- socketHost: This indicates which address the server should bind to (the default is localhost). Example:
[server]
socketHost=192.168.0.23
- socketFile: This is only used on Unix, if you want to use an AF_UNIX socket instead of a regular AF_INET socket. Example:
[server]
socketFile=/tmp/mySocket.soc
- forking: Set this to 1 if you want a forking server. Example:
[server]
socketPort=80
forking=1
- threading: Set this to 1 if you want a threading server. Example:
[server]
socketPort=80
threading=1
- processPool: Set this to n (n>1) if you want to have n processes created at startup. Example:
[server]
socketPort=80
processPool=10
- threadPool: Set this to n (n>1) if you want to have n threads created at startup. Example:
[server]
socketPort=80
threadPool=10
- reverseDNS: Set this to 1 if you want to enable reverse DNS (this way the full name of the domain name for the clients will be written to the logs). The default is 0. Example:
[server]
socketPort=80
reverseDNS=1
- socketQueueSize: Size of the socket queue (this value will be passed to the listen() function). The default is 5. Example:
[server]
socketPort=80
socketQueueSize=5
- sslKeyFile and sslCertificateFile: This is used to have an SSL server. There is a HowTo in the documentation about it.
- xmlRpc: This is used to have an XML-RPC server. There is a HowTo in the documentation about it.
Some of these options obviously cannot be used together because they conflict:
- socketFile and socketPort obviously conflict with each other
- threading, forking, processPool and threadPool obviously conflict with each other
See About this document... for information on suggesting changes.