There are two methods of invoking Rocket. The first is the native method which exposes the full capabilities of Rocket to the developer.
from rocket import Rocket
from wsgiref.simple_server import demo_app
server = Rocket(('127.0.0.1', 80), 'wsgi', {"wsgi_app":demo_app})
server.start()
The second is a simple CherryPy adapter to make Rocket work as a drop-in replacement for the CherryPy WSGI server.
from rocket import CherryPyWSGIServer
from wsgiref.simple_server import demo_app
server = CherryPyWSGIServer(('127.0.0.1', 80), demo_app)
server.start()
See the API Reference below for more details on all available options. Also the source distribution contains an examples directory with a ready-to-run example of each method type.
Rocket makes use of Python’s built-in optimization. Turning on optimization will skip evaluation of debug messages and speed things up a little. This doesn’t happen automatically, you’ll need to turn it on specifically either by environment variable or command-line option.
Rocket uses the standard Python logging module for logging. It provides three classes of logs:
- “Rocket.Requests” - HTTP Requests are logged here at the INFO level.
- “Rocket.Errors” - Errors are logged here at the appropriate level.
- “Rocket” - This log class will encompass all log messages
To log messages to a file, do something like this before running Rocket().start():
import logging
import logging.handlers
log = logging.getLogger('Rocket')
log.setLevel(logging.INFO)
log.addHandler(logging.handlers.FileHandler('rocket.log'))
Rocket(interfaces, method, app_info, min_threads, max_threads, queue_size, timeout)
interfaces - Either a tuple or list of tuples that specify the listening socket information. Each tuple contains a string-based IP address, an integer port number and, optionally, a key file path and a certificate file path. For example:
('127.0.0.1', 80)
will serve only to localhost on port 80. To serve on all interfaces, specify the IP address of 0.0.0.0 along with the desired port number. interfaces can also be a list of such tuples specifying all interfaces on which the Rocket server will respond to requests. For example:
[('0.0.0.0', 80), ('0.0.0.0', 443, 'server_key.pem', 'server_cert.pem')]will serve HTTP on port 80 to clients from any address and HTTPS on port 443 to clients from any address. Note that if you are using Rocket on a version of Python less than 2.6, you will have to install the ssl module manually since the HTTPS feature depends on it.
If you do not have a server key and certificate and just need a self-signed certificate, you can generate one with OpenSSL. The Python documentation has more details on how to do this.
NOTE: The CherryPyWSGIServer adapter does not support SSL in the typical way that CherryPy’s server does. Instead, pass an interfaces-like list or tuple to CherryPyWSGIServer and it will be handled as Rocket does natively.
ALSO NOTE: There is a key-certificate pair in the tests directory (in the source distribution). Feel free to use these for testing. DO NOT USE THE INCLUDED CERTIFICATES FOR A PRODUCTION WEBSITE! You have been warned.
CherryPyWSGIServer(interface, wsgi_app, numthreads, server_name, max, request_queue_size, timeout, shutdown_timeout)
An instance of Rocket (or CherryPyWSGIServer) two methods for external use:
For Jython running CPU-bound applications, use 1.5 times the number of CPU cores for both min_threads and max_threads.
For cPython, use a reasonable number of min_threads (10 for a small server or development server, 64 for a production server) with no limit set to max_threads.
Rocket is tested to run with both cPython and Jython. Which are very different platforms from a concurrency perspective. This has an impact on how Rocket should be configured on each platform.
Because of its GIL, cPython keeps one process on one CPU regardless of the number of running threads. Threads are used in cPython to allow other work to go on while some portions are blocked on external operations such as database queries or file reads. For this reason, it is advantageous to have a large number of threads running.
Jython, on the other hand, has no GIL and is fully multi-threaded with fine-grained locking. The downside of this is that many threads will sit and lock on global resources. Starvation is a major problem for CPU-bound servers with a high number of threads. If your web application is largely I/O bound, then a large number of threads is perfectly fine. But for CPU-bound applications, having a large number of threads will dramatically decrease the performance of Rocket on Jython. The recommended number for max_threads for Rocket on CPU-bound applications is 1.5 * the number of CPU-cores. For example, a server with 2 dual-core processors has 4 cores. The recommended maximum number of threads for Jython would be 6 for CPU-bound applications. Since this is such a low number compared to the cPython recommendations, setting max_threads and min_threads to an equal number will prevent the threadpool from dynamically flexing the thread pool (thus saving a little more processor power).