uWSGI

uwsgi 相关问题整理

0.什么是uWSGI?

WSGI 是 web server gateway interface 的简写
uWSGI 是一个web 服务,实现了WSGI协议、uwsgi 协议、http 等协议.nginx 中HttpUwsgiModule的作用是与uWSGI服务器进行交互.
为什么有了uWSGI 还需要nginx?
因为nginx具有优秀的静态内容处理能力,然后将动态内容转发给uWSGI 服务器这样可以达到很好的客户端响应.

1.为什么要使用uwsgi?使用后有什么优势?

2.nginx 的一些常见配置或者优化参数

1.优化进程数量

worker_processes 1 # 指定nginx 要开启的进程数,可以为auto

进程数的优化策略: worker 进程数可以设置为等于CPU核数,根据实际情况可以适当提高.设置为CPU核数是官方建议的参数.
设置为auto 由nginx 自行决定worker数量.访问量快速增加是nginx会fork 新进程来缩短系统的瞬时开销,降低服务的时间.
2.将不同的进程绑定到不同的CPU
默认情况,nginx的多个进程有可能运行在同一个CPU 核上,导致Nginx 进程对服务器的利用率下降.这种情况下需要将进程分布到不同核上,
提高硬件的利用率.配置参数如下

worker_processes 4
worker_cpu_affinity 0001 0010 0100 1000

参数中worker_cpu_affinity 就是配置nginx 进程与cpu 亲和力的参数,把不同的进程分给不同的CPU核处理,
0001 0010 0100 1000是掩码,分别代表1、2、3、4核CPU.上面的配置会为每个进程分配一核CPU.也可以将
worker_cpu_affinity 设置为auto由nginx进行配置

3.Nginx 事件处理模型优化
nginx 连接处理在不同操作系统下会采用不同的I/O模型,在linux 下,Nginx 使用epoll 的I/O多路复用模型,在freeBSD下使用kqueue的I/O多路复用模型
在Solaris中使用/dev/poll方式的I/O 多路复用模型,在Windows 使用icop等
可以手动配置

    events {
        use poll
    }

events 指令是设定Nginx 的工作模式及连接数上限,use 指令用来指定Nginx 的工作模式.
Nginx 支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll.也可以不指定事件处理模型,由Nginx 自动进行选择

4.单个进程允许的客户端最大连接数

events {
    worker_connections 20480
}

work_connections 是事件模块指令,用于定义Nginx 每个进程的最大连接数,默认是1024.
最大连接数的计算公式为
max_clients = worker_processes * worker_connections
如果是作为方向代理,因为默认浏览器会开始2个连接到server,而且nginx 还会使用fds(file descriptor)
从同一个连接池建立连接到upstream 后端,则最大连接数的计算公式为:
max_clients = worker_processes * worker_connections / 4;
另外,进程的最大连接数受Linux 系统进程的最大打开文件数限制,在自行操作系统命令ulimit -HSn 65535或配置相应文件后,
worker_connections的设置才能生效

5.配置获取更多连接数
默认情况,Nginx 进程只会在一个时刻接受一个新的连接,我们可以配置multi_accept 为on,实现在一个时刻内可以接收多个新的连接,提高处理效率.
该参数默认是off,建议开启

events {
    multi_accept on;
}

6.配置worker进程的最大打开文件数
调整配置nginx worker 进程的最大打开文件数,这个控制连接数的参数为worker_rlimit_nofile

worker_rlimit_nofile 65535;

可设置为系统优化后的ulimit -HSn 的结果
7.优化域名的散列表大小

http {
    server_name_hash_bucket_size 128;
}

这个参数的作用:设置存放域名(server names)的最大散列表的存储桶的大小.默认值依赖CPU 的缓存行
server_name_hash_bucket_size 的值是不能带单位的.配置主机时必须设置该值,否则无法允许nginx 或者无法通过测试.
该设置与server_names_hash_max_size共同控制保存服务器的hash表,hash_bucket size 总是等于hash 表的大小,
并且是一路处理器缓存大小的倍数.若hash bucket size等于一路处理器缓存的大小,那么在查找键时,最坏的情况下在内存中查找的次数为2.第一次是确定存储单元的地址,第二次是在存储单元中查找键值.
若报出hash max size 或者hash buckect size 的提示则需要增加server_names_hash_max_size的值,

8.TCP优化

http {
    sendfile on;
    tcp_nopush on;

    keepalive_timeout 120;
    tcp_nodelay on;
}

sendfile 配置可以提高Nginx 静态资源托管效率.sendfile 是个系统调用,直接在内核空间完成文件发送,
不需要先read 再write,没有上下文切换开销

tcp_nopush 是freebBSD的一个sockect 选项,对应Linux 的TCP_CORK,Nginx 里统一用tcp_nopush 来控制,
并且在启用来sendfile 之后才生效.启用他之后数据包会累计到一定大小之后才会发送,减小了额外开销,提高网络效率.

tcp_nodelay 也是一个cokect 选项,启用后会禁用nagle 算法,尽快发送数据,
某些情况下可以节约200ms(Nagle 算法是:在发出的数据还未被确认之前,新生成的小数据先存起来,凑满一个MSS 或者等到收到确认后再发送).
nginx 只会针对处于keep-alive 状态的tcp连接才会启用tcp_nodelay

9.优化连接参数

http {
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;
    client_max_body_size 1024m;
    client_body_buffer_size 10m;
}

根据业务场景而定,client_max_body_size 用来决定请求体的大小,用来限制上传文件的大小.上面具体参数可以作为起始参数

10.配置压缩优化
(1).gzip压缩
通常在上线前,代码(js、css、html)会压缩,图片也会压缩(pngout、pngcrush、jepgOptim、Gitsicle等).
对于文本文件,服务端在发送响应之前进行Gzip压缩也很重要,通常压缩后的文本大小会减小到原来的1/4 ~1/3.

http {
    gzip on;
    gzip_buffer 16 8k;
    gzip_comp_level 6;
    gzip_http_version 1.0;
    gzip_min_length 1000;
    gzip_proxoed any;
    gzip_vary on;
    gzip_types
        text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
        text/javascript application/javascript application/x-javascript
        text/x-json application/json application/x-web-app-mainfest+json
        text/css text/plain text/x-component
        font/opentype application.x-font-off application.vnd.ms-fontobject
        image/x-icon;
    gzip_disable "MISE [1-6]\.(?!.*SV1)";
}

如上配置中,gzip_vary 用来输出vary响应头,用来某些缓存服务的一些问题
gzip_disbale 指令接收一个正则表达式,当请求头中的UserAgent 字段满足这个正则时,响应不会启用Gzip.这是为了解决在某些浏览器启用Gzip带来的问题
默认Nginx 只会在HTTP/1.1 及以上的请求才会启用Gzip 这是因为部分HTTP/1.0 客户端在处理Gzip时有Bug.现在基本可以忽略这种情况,
因此可以指定gzip_http_version 1.0来针对HTTP/1.0 及以上的请求开启Gzip.

(2).Brotli压缩
Brotli 是基于LZ77 算法的一个现代变体、霍夫曼编码和二阶上下文建模.Google 工程师在2015年9月发布了包含通用无损压缩的Brotli增强版本
特别侧重于HTTP压缩.其中的编码器被部分改写以提高压缩比,编码器和解码器速度都得到了提高,流式API 已被改进,增加更多压缩质量级别
需要安装依赖包 libbrotli、nginx_brotli 重新编译Nginx 带上–add-module=.path/to/ngx_brotli即可,然后配置如下

http {
    brotli on;
    brotli_comp_level 6;
    brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
}

brotli 可与Gzip 共存在一个配置文件中

  1. 静态资源优化
    静态资源优化,可以减少连接请求数,同时也不需要对这些资源请求打印日志,副作用是资源更新可能无法及时
server {
    # 图片、视频
    location ~ .*\.(gif|jpg|jepg|png|bmp|swf|flv|mp4|ico)${
        expires 30d;
        access_log off;
    }
    location ~ .*\.(eot|ttf|otf|woff|svg){
        expires 30d;
        access_log off;
    }
    location ~ .*\.(js|css)?$ {
        expires 7d;
        access_log off;
    }
}

更多可参考https://learnku.com/articles/36768

2.uWSGI 底层原理

官方代码库 位于https://github.com/unbit/uwsgi
参考 https://segmentfault.com/a/1190000011365430···

All posts

Other pages