Deployment Recommendations

The table below lists common Python application deployment solutions, describing their advantages, disadvantages, and usage recommendations.

Category	Application Server	Pros & Cons	Framework
WSGI	UWSGI	Multi-process, multi-thread, synchronous	All WSGI protocol frameworks
WSGI	Gunicorn	Multi-process, IO asynchronous	All WSGI protocol frameworks
WSGI	Gevent	Single process, IO asynchronous	All WSGI protocol frameworks
Non-WSGI	Tornado	Single process, network asynchronous	Not recommended for WSGI App/Tornado

UWSGI Deployment

Advantages

The advantage of deploying applications with UWSGI is the precise control over application startup parameters, start/restart conditions, detailed debugging information, and more control, debugging, and signal interfaces. It is a traditional multi-process deployment solution, widely used, and offers flexible and diverse configuration options.

Disadvantages

It relies entirely on hardware resources. Once hardware bottlenecks are reached, issues such as unresponsiveness or deadlocks may occur. However, if you can accurately predict and control application access (such as with load balancing and backup hardware resources), it can still be a good choice.

Deployment Recommendations

To better support the agent, it is recommended to enable the following UWSGI options:

--enable-threads: By default, UWSGI does not enable multi-threading support. Since the agent is based on a multi-threaded model, this option must be enabled; otherwise, the agent cannot start properly. If UWSGI uses the --threads option, --enable-threads will be enabled automatically.

--single-interpreter: By default, UWSGI starts subprocesses to run applications for environment isolation, rather than running them in the main process. To better adapt to the agent environment, enable this option. It is safe and effective, with no side effects.

--lazy: When enabled, UWSGI loads the app in worker processes instead of the master. This does not affect normal operation, as the master only handles scheduling and does not process requests.

Gunicorn & Gevent

Advantages

Essentially, there is little difference between the two. Gevent is based on the libevent IO library, while Gunicorn can use Gevent or greenlet as its worker service. Gunicorn manages workers in a multi-process manner (which can be gevent, etc.), while Gevent is generally deployed as a single process.

Both are event-driven asynchronous IO models, offering higher concurrency than UWSGI's synchronous approach and making better use of server resources.

Disadvantages

Compared to UWSGI, the disadvantages are also obvious: process state monitoring and information transparency are lower, and flexibility is not as high.

Deployment Recommendations

The agent currently supports deployment with asynchronous application servers. Due to their asynchronous nature, try to avoid excessive or large IO and network blocking operations during development, and ensure proper load balancing. If the request volume is high, too many process data may reside in memory, leading to excessive memory consumption. Especially when there are many slow requests, the agent may collect too much information, increasing resource consumption.

Tornado

Advantages

Tornado excels at network asynchronous concurrency, easily supporting thousands of concurrent network requests on a single machine and process. It also provides excellent support for long connections.

Disadvantages

Developing applications based on Tornado is more challenging. To fully leverage Tornado's asynchronous network features, applications need to use its asynchronous interfaces (such as for database operations, file IO, etc.); otherwise, performance will be significantly reduced.

Deployment Recommendations

Common Tornado deployment solutions are as follows:

Solution	Application Server	Framework/Application	Description
A	Tornado App	Tornado	Native deployment method
B	Tornado App	WSGI App	Not recommended; refer to UWSGI Deployment or Gunicorn & Gevent
C	WSGI Server	Tornado App	Not recommended

Solution A:

The agent currently only supports Tornado 3.X and 4.X versions. Use the agent as usual for these versions.

Solutions B & C:

Enable Tornado WSGI compatibility mode. Set the tornado_wsgi_adapter_mode option in the agent configuration file.