Using NGINX to maximize Python performance, Part one: WEB Services and caching

"Editor's note" This article mainly introduces the main features of Nginx and how to optimize Python application performance through Nginx. This article is a domestic ITOM management platform OneAPM compiled rendering.

Python is famous for its simplicity and ease of use, its simplicity in software development, and its reportedly better performance than other scripting languages. (although the latest version of PHP, PHP 7 May compete fiercely with it.) ）

Everyone wants their sites and applications to run faster. However, each site is prone to performance problems or even downtime when traffic is growing or spikes in traffic (which typically happens when the server is busiest). In addition, almost all websites experience performance problems during the run, whether it's a steady increase in traffic or a rapid spike in usage.

And about the performance of the site, it is the Nginx and Nginx Plus play a role. There are three ways to improve your website's performance in general:

as a Web server , NGINX was originally designed to solve the c10k problem, that is, to easily support more than 10,000 of simultaneous access. NGINX as a Python Web server, you can ensure that the site in low traffic will still be able to run quickly. When you have thousands of users accessing at the same time, you have to provide a Web server with higher performance, fewer crashes, and less downtime. You can also perform a static file cache or a micro-program cache on the Nginx server, but both perform better on a separate Nginx reverse proxy server (see next paragraph).

do a reverse proxy server -you can set NGINX as the reverse proxy server on the current application server. NGINX sends a network request to the application server. This quirky trick can improve website performance, reduce downtime, reduce server resource usage, and improve website security. You can also cache static data (very efficient) on the reverse proxy server, increasing the micro-program cache of Dynamic data, thereby reducing the burden on the application itself.

Load balancer for multiple application servers -First deploy a reverse proxy server, then run multiple application servers at the same time, and use Nginx or nginx Plus to scale the traffic that passes through them. With this deployment, you can easily measure website performance, increase reliability and uptime based on traffic requirements. If you need an established user session to be saved on the same server, configuring the load balancer can also support session persistence.

Whether you use it as a Python Web server, a reverse proxy server, a load balancer, or both of these three features, Nginx and Nginx Plus can be a great benefit.

Here are 5 tips to improve the performance of Python applications, which are described in several chapters, including Nginx and Nginx Plus as a Web server, how to implement a static file cache, and a micro-program cache application generation file.

Then the next article will show you how to treat Nginx and Nginx Plus as a reverse proxy server and multiple application server load balancer.

Tip 1-Find Python performance bottlenecks

There are two different scenarios for verifying the performance of a Python application.

The first is in the case of a reasonable number of daily users, and the second is under heavy load.

Many stationmaster does not care about the light load when the website performance, but the brutal reality experience tells us, the response time every second should be nieyibahan for it. While shortening the response time by a few milliseconds is a chore, it can lead to better user experience and better operational outcomes.

The other is the situation that everyone is worried about: performance issues that occur when the site is busy, such as running a severe slowdown and crashing. In addition, many hacker attacks will also show a sharp increase in the number of users, so improving website performance is also an important step to solve the attack problem.

The server allocates a certain amount of memory for each user, such as the Apache HTTP server, and as the number of users grows, the physical memory is overloaded, the server begins to exchange data to disk, the performance dips, and the performance is poor and crashes. The use of NGINX will help solve this problem.

Python is particularly prone to memory-related performance issues because it typically consumes more memory than other scripting languages when performing tasks (so it executes more quickly). Therefore, under the same conditions, Python-based applications may be less user-loaded than other language applications.

Optimizing applications is more or less helpful, but this is not usually the best or fastest solution for traffic-related site performance issues. The following article lists the best/fastest solution for resolving traffic-related issues. When you're finished with this article, go back and optimize your application anyway, or rewrite it using the microservices architecture.

Tip 2-Select Single server or multiple server configurations

Small sites can run well as long as a single server is configured, and large sites require multiple servers. And if you're in the middle of something, or your website is growing up from a small website, you have to make some interesting choices.

If you only have the ability to configure a single server, you are at great risk when traffic spikes or overall traffic grows rapidly. Because your scalability is limited at this point, the solution can include optimizing the application, changing the Web server to NGINX, switching to a larger and faster server, or moving the storage task to a content distribution network (CDN), and so on. Each of these options can be time-consuming, cost-intensive, and may introduce errors and problems in the implementation process.

In addition, the configuration of a single server, your site has a single failure node, there will be a lot of problems caused your site offline and there is no quick and simple solution.

If you change the configuration of a single server to use Nginx, you can freely choose Open-source Nginx software or Nginx Plus. NGINX Plus includes enterprise-class support and additional features. Some additional features can be implemented in a single-server configuration, such as real-time activity monitoring, and some features are only present when NGINX Plus is used as a reverse proxy server for multiple server configurations, such as load balancing and session persistence.

With all of this in mind, you can configure a single server unless you are sure that your site will not scale up for a long time to come, stop running, and be able to resist some other risk. But don't forget to configure multiple servers to scale almost arbitrarily-a single failure can be fully processed, can quickly expand capacity, in short, your application performance is determined by you.
Tip 3–change Your Web Server to NGINX

Tip 3-Change your Web server to NGINX

In the early days of network development, Apache was equivalent to a Web server. But since the early 21st century NGINX was used more and more widely, it has become the world's top 1000, 10000 and 100000 of the company's Web server preferred.

NGINX is designed to solve the c10k problem, that is, in a given memory budget within the scope of supporting more than 10000 of simultaneous access. Other Web servers need to allocate a portion of memory to each access, but when thousands of users visit the site at the same time, they face problems with insufficient physical memory, slow running, or crashes. NGINX handles each request separately, and can gracefully handle more users. (as mentioned above, it also has excellent performance in other functions.) ）

The following is an overview of the NGINX architecture.

In this figure, there is a background application block for a Python application server that needs to be accessed through FastCGI. NGINX does not know how to run Python, so it needs a gateway to enter an environment that can run Python. FastCGI is a widely used user interface in languages such as PHP and Python.

However, the more common alternative to communication between Python and NGINX is the Service Gateway Interface (WSGI). WSGI can run in a multithreaded, multi-process environment, so it can be run under all the configuration choices mentioned in this article.

If you want to make NGINX your Web server, there are a lot of helpful information on the Internet:

• Configure the gunicorn-green Unicorn, a well-known WSGI server to use NGINX.
• Configure uwsgi-Another well-known WSGI server in order to use NGINX. Uwsgi can directly support NGINX.
• Use Uwsgi, NGINX, and django-a very common Python site framework.

The following fragment shows how to configure NGINX to run with Uwsgi (the given instance is a project using the Python framework Django):

http {    ...    upstream django {       server 127.0.0.1:29000;    }    server {        listen 80;        server_name myapp.example.com;        root /var/www/myapp/html;        location / {            index index.html;        }        location /static/  {            alias /var/django/projects/myapp/static/;        }        location /main {            include /etc/nginx/uwsgi_params;            uwsgi_pass django;            uwsgi_param Host $host;            uwsgi_param X-Real-IP $remote_addr;            uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;            uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;        }    }}

Tip 4--Implementing a static data cache

A static data cache consists of a file that is not frequently changed (perhaps a few hours, perhaps forever) that exists outside of an application server. A typical example of a static file is a JPEG image that is displayed as part of a page's content.

Static file caching is a common way to enhance application performance, and in fact occurs at several levels:

• In the user's browser
• Multiple tiers of network providers-from a company intranet to an Internet service provider (ISP)
• Web server, as described in this article

There are two benefits of implementing a static data cache on a Web server:

• Faster transfer to user-nginx is optimized for static data caching, and requests to perform static content are much faster than application servers.
• Reduce the burden on the application server-the application server does not even receive requests to cache static data because the network server has implemented these requests.

The static file cache runs well when a single server executes, but the hardware is still shared by the Web server and the application server. If the Web server uses hardware to retrieve cached files (in a timely and very efficient manner) applications will not be able to use these hardware, the running speed may be affected.

To support browser caching, set the HTTP header correctly for static files. You need to consider the HTTP cache control header (especially its max?age settings), the Expires header, and the entity label. To learn more about this, you can refer to Using NGINX as an application Gateway with Uwsgi and Django.

The following code configures NGINX, which is used to cache various types of static files, including JPEG files, GIF, PNG files, MP4 video files, PPT, etc. (using your URL instead of www.example.com):

server {    # substitute your web server‘s URL for "www.example.com"    server_name www.example.com;    root /var/www/example.com/htdocs;    index index.php;    access_log /var/log/nginx/example.com.access.log;    error_log /var/log/nginx/example.com.error.log;   location / {        try_files $uri $uri/ /index.php?$args;    }   location ~ \.php$ {        try_files $uri =404;        include fastcgi_params;        # substitute the socket, or address and port, of your Python server        fastcgi_pass unix:/var/run/php5-fpm.sock;        #fastcgi_pass 127.0.0.1:9000;    }     location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg                  |jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid                  |midi|wav|bmp|rtf)$ {        expires max;        log_not_found off;        access_log off;    }}

Tip 5-Implement the micro-program cache

The micro-Program cache provides a great opportunity for application servers running Python, PHP, and other languages to improve performance. There are 3 types of pages that can be cached:

• Static files-cacheable, see Tip 4.
• Application-generated, non-personalized pages-in general, caching doesn't make sense because the content needs to be constantly updated. For example, the page that users see when they log on to the e-commerce site (see next paragraph)-items for sale, recommendations for similar products, etc. may be constantly updated, so it is important to provide the latest Web pages. However, if another user logs in after a very second, it's not a problem to show them the same page that the previous user saw.
• Application-generated, personalized pages-these are usually not cached because they are individual users, and the same user does not see the same page again. For example, when a user logs on to an e-commerce website, the same page cannot be displayed to other users.

The micro-program cache is useful for the second page type mentioned above-the application-generated, non-personalized page. Micro is a generalization of the time range. If your site generates the same page several times in a second, the cache will not affect the freshness of the page for a second. However, this generalized cache time period can greatly reduce the burden on the application server, especially during peak process periods. Instead of generating 10, 20, 100 (the same content) within the cache timeout period, a given page is generated once, and the page is cached and displayed to multiple users through caching.

And the effect is incredible, the server processing a large number of requests a second slow, but the speed is very fast when processing only one request. (Of course, there are any personalized pages). Setting a proxy server with a timeout of one second requires only a few lines of configuration code for such a core change.

proxy_cache_path /tmp/cache keys_zon\=cache:10m levels=1:2 inactive=600s max_size=100m;server {    proxy_cache cache;    proxy_cache_valid 200 1s;    ...}

For more configuration examples, please refer to Tyler Hicks? Wright's blog Python and Uwsgi with NGINX.

Conclusion

In this section, this article describes a solution to improve the performance of a single server boost Python application that can be configured on a single server or on a reverse proxy server or a separate cache server. (The cache runs better on a separate server.) The second part of the next section describes the performance improvement scenarios that require two or more servers to implement.

Of course, if you want to know the advanced features of Nginx Plus for your application, such as support, real-time activity monitoring, and runtime configuration, you can go to the Nginx website to view.

OneAPM can help you see every aspect of your Python application, not only to monitor the user experience of the terminal, but also to monitor server performance, while also supporting the tracking of databases, third-party APIs, and WEB server issues. To read more technical articles, please visit the OneAPM Official technology blog.

This article was transferred from OneAPM official blog

Original address: Maximizing Python performance with NGINX, part i:web serving and Caching

Using NGINX to maximize Python performance, Part one: WEB Services and caching