This is the command gunicorn3 that can be run in the OnWorks free hosting provider using one of our multiple free online workstations such as Ubuntu Online, Fedora Online, Windows online emulator or MAC OS online emulator
PROGRAM:
NAME
gunicorn - Event-based HTTP/WSGI server
SYNOPSIS
gunicorn [OPTIONS] APP_MODULE
OPTIONS
-c CONFIG, --config=CONFIG
Config file. [none]
-b BIND, --bind=BIND
Address to listen on. Ex. 127.0.0.1:8000 or unix:/tmp/gunicorn.sock
-w WORKERS, --workers=WORKERS
Number of workers to spawn. [1]
-a ARBITER, --arbiter=ARBITER
gunicorn arbiter entry point or module [egg:gunicorn#main]
-p PIDFILE, --pid=PIDFILE
Set the background PID FILE
-D, --daemon
Run daemonized in the background.
-m UMASK, --umask=UMASK
Define umask of daemon process
-u USER, --user=USER
Change worker user
-g GROUP, --group=GROUP
Change worker group
-n PROC_NAME, --name=PROC_NAME
Process name
--log-level=LOGLEVEL
Log level below which to silence messages. [info]
--log-file=LOGFILE
Log to a file. - equals stdout. [-]
d, --debug
Debug mode. only 1 worker.
--version
Show program's version number and exit
-h, --help
show this help message and exit
DESCRIPTION
Green Unicorn (gunicorn) is an HTTP/WSGI server designed to serve fast clients or sleepy
applications. That is to say; behind a buffering front-end server such as nginx or
lighttpd.
* Optional support for Eventlet and Gevent to provide asynchronous
long-polling ("Comet") connections.
* Process management: Gunicorn reaps and restarts workers that die.
* Easy integration with Django and Paster compatible applications (Pylons,
TurboGears 2, etc.
* Load balancing via pre-fork and a shared socket
* Graceful worker process restarts
* Upgrading without losing connections
* Decode chunked transfers on-the-fly, allowing upload progress notifications
or stream-based protocols over HTTP
TUNING
KERNEL PARAMETERS
There are various kernel parameters that you might want to tune in order to deal with a
large number of simultaneous connections. Generally these should only affect sites with a
large number of concurrent requests and apply to any sort of network server you may be
running. They're listed here for ease of reference.
The commands listed are tested under Mac OS X 10.6. Your flavor of Unix may use slightly
different flags. Always reference the appropriate man pages if uncertain.
INCREASING THE FILE DESCRIPTOR LIMIT
One of the first settings that usually needs to be bumped is the maximum number of open
file descriptors for a given process. For the confused out there, remember that Unices
treat sockets as files.
$ sudo ulimit -n 1024
INCREASING THE LISTEN QUEUE SIZE
Listening sockets have an associated queue of incoming connections that are waiting to be
accepted. If you happen to have a stampede of clients that fill up this queue new
connections will eventually start getting dropped.
$ sudo sysctl -w kern.ipc.somaxconn="1024"
WIDENING THE EPHEMERAL PORT RANGE
After a socket is closed it eventually enters the TIME_WAIT state. This can become an
issue after a prolonged burst of client activity. Eventually the ephemeral port range is
used up which can cause new connections to stall while they wait for a valid port.
This setting is generally only required on machines that are being used to test a network
server.
Use gunicorn3 online using onworks.net services
