gunicorn_paster(1) [debian man page]

GUNICORN_PASTER(1)					User Contributed Perl Documentation					GUNICORN_PASTER(1)

NAME

       gunicorn_paster - Event-based HTTP/WSGI server, Paste application entry-point

SYNOPSIS

       gunicorn_paster [OPTIONS] [SETTINGS_PATH]

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.

SEE ALSO

       gunicorn(1)

perl v5.14.2							    2012-10-04							GUNICORN_PASTER(1)

Check Out this Related Man Page

SYSTEMD-SOCKET-PROXYD(8)				       systemd-socket-proxyd					  SYSTEMD-SOCKET-PROXYD(8)

NAME

       systemd-socket-proxyd - Bidirectionally proxy local sockets to another (possibly remote) socket.

SYNOPSIS

       systemd-socket-proxyd [OPTIONS...] HOST:PORT

       systemd-socket-proxyd [OPTIONS...] UNIX-DOMAIN-SOCKET-PATH

DESCRIPTION

       systemd-socket-proxyd is a generic socket-activated network socket forwarder proxy daemon for IPv4, IPv6 and UNIX stream sockets. It may be
       used to bi-directionally forward traffic from a local listening socket to a local or remote destination socket.

       One use of this tool is to provide socket activation support for services that do not natively support socket activation. On behalf of the
       service to activate, the proxy inherits the socket from systemd, accepts each client connection, opens a connection to a configured server
       for each client, and then bidirectionally forwards data between the two.

       This utility's behavior is similar to socat(1). The main differences for systemd-socket-proxyd are support for socket activation with
       "Accept=false" and an event-driven design that scales better with the number of connections.

OPTIONS

       The following options are understood:

       -h, --help
	   Print a short help text and exit.

       --version
	   Print a short version string and exit.

       --connections-max=, -c
	   Sets the maximum number of simultaneous connections, defaults to 256. If the limit of concurrent connections is reached further
	   connections will be refused.

EXIT STATUS

       On success, 0 is returned, a non-zero failure code otherwise.

EXAMPLES

   Simple Example
       Use two services with a dependency and no namespace isolation.

       Example 1. proxy-to-nginx.socket

	   [Socket]
	   ListenStream=80

	   [Install]
	   WantedBy=sockets.target

       Example 2. proxy-to-nginx.service

	   [Unit]
	   Requires=nginx.service
	   After=nginx.service
	   Requires=proxy-to-nginx.socket
	   After=proxy-to-nginx.socket

	   [Service]
	   ExecStart=/lib/systemd/systemd-socket-proxyd /tmp/nginx.sock
	   PrivateTmp=yes
	   PrivateNetwork=yes

       Example 3. nginx.conf

	   [...]
	   server {
	       listen	    unix:/tmp/nginx.sock;
	       [...]

       Example 4. Enabling the proxy

	   # systemctl enable --now proxy-to-nginx.socket
	   $ curl http://localhost:80/

   Namespace Example
       Similar as above, but runs the socket proxy and the main service in the same private namespace, assuming that nginx.service has PrivateTmp=
       and PrivateNetwork= set, too.

       Example 5. proxy-to-nginx.socket

	   [Socket]
	   ListenStream=80

	   [Install]
	   WantedBy=sockets.target

       Example 6. proxy-to-nginx.service

	   [Unit]
	   Requires=nginx.service
	   After=nginx.service
	   Requires=proxy-to-nginx.socket
	   After=proxy-to-nginx.socket
	   JoinsNamespaceOf=nginx.service

	   [Service]
	   ExecStart=/lib/systemd/systemd-socket-proxyd 127.0.0.1:8080
	   PrivateTmp=yes
	   PrivateNetwork=yes

       Example 7. nginx.conf

	   [...]
	   server {
	       listen	    8080;
	       [...]

       Example 8. Enabling the proxy

	   # systemctl enable --now proxy-to-nginx.socket
	   $ curl http://localhost:80/

SEE ALSO

       systemd(1), systemd.socket(5), systemd.service(5), systemctl(1), socat(1), nginx(1), curl(1)

systemd 237														  SYSTEMD-SOCKET-PROXYD(8)

Linux and UNIX Man Pages

gunicorn_paster(1) [debian man page]

Check Out this Related Man Page