uwsgi

                                      为什么不使用mod_wsgi

wsgi可以看成一种编程标准，而不是一个socket协议，他不同于fastcgi它是一个通信协议

Python web程序，布署起来常见的有两种方法：

1.一种是使用框架本身自带的的server服务器调用wsgi接口来调用我们的web app应用程序，而因为我们的框架开发能力有限，不可能开发出一套很稳定，负载功能等各方面能力都很强的server服务器，只能开发除一个简单的测试用的server服务器。

在生产环境中：这就决定了我们必须布署并使用一个外部的性能很高的服务器，做为我们的python web app应用程序的服务器。

2.使用各种http服务器的mod_wsgi模块来运行链接各种python web app应用程序。但是使用mod_wsgi模块功能简单，不能监控，负载能力也不强，性能也不强，而且很占用内存，配置起来也很麻烦，可以这么理解，这个项目组的人员只是兼职开发了这么一个模块，所以性能不高，不如专业开发这种接口模块的人员开发的功能模块强，这个功能模块就是uWSGI。

uWSGI，既不用wsgi协议也不用fcgi协议，而是自创了一个uwsgi的协议栈类似于PHP中的php-cgi一样能统一监听同一个端口，进行统一负载平衡和管理，提高了性能，节省了部署功夫，而且据说该协议栈大约是fcgi协议的10倍那么快，有个比较见下图，

为什么我们要使用uWSGI（这也是一个经常要被问到的问题）

Because：因为：

我们uWSGI的目标是：要想成为一个完整的集成各种功能的web应用程序布署中间件，他要有各种层级，他的功能要包括：

1. 进程管理
2. 一个长时间运行的web 应用程序app任务的自动管理（对于长时间运行的web app任务的稳定性要提除出各种解决办法）

         3.uWSGI RPC Stack：uWSGI想要包含一个完成的远程调用协议栈。

         4.Clustering 集群功能：能使用集群功能

1. LoadBalancing：负载均衡：可以直接管理并调用好几个app。
2. Monitoring：监控功能：具有对对各个web app应用程序的监控功能。
3. Resource Limiting：资源限制功能，比如负载均衡调用好几个app，可以分别对他们进行资源限制，比如网速，每个app单位时间内的调用请求次数进行限制，这样能提高我们好几个web app集合的整体性能。

以及其他一些令人烦恼的日常任务，比如你要委托给外部脚本和其他需要调用系统才能查看的任务，比如前面的监控功能。

所以：如果你想寻找一个简单使用的适用于WSGI,PSGI或者是Rack协议的server，uWSGI可能不适合你，那就不要选择uWSGI了。但是，如果你建立一个坚固，快速，容易部署并能配合达到一个各种性能最优化的负载均衡部署，你可能会发现自己需要uWSGI。

uWSGI最好的定义：就是网络应用程序的瑞士军刀。

这是一种什么协议：

uwsgi 是 根据SCGI衍生出来的一种新的协议：

能在集群环境中使用他们吗

能使用集群功能是uWSGI协议栈的一个主要特点，我们可以将多个实例部署在不同的服务器上，并利用负载均衡设备你的服务器/代理/路由器，您能把您的负载分配。像uWSGI RPC远程调用系统能栈系统允许你快速调用的远程节点上的功能，uWSGI协议栈系统允许你在多个节点上选出一个主节点进行方便配置管理。

超时设定

超时设定功能是保证集群节点高可用性的一个关键功能。

Uwsgi帮助：

uWSGI是一个包换数百个功能选项的巨大工程。你应该做好准备，不是每件事都会在第一枪中出现。寻求帮助，寻求帮助，寻求帮助。如果你感到沮丧，不要浪费时间抱怨咆哮-而不是简单地加入列表，并请求帮助。这是开源的，如果你只抱怨，那你什么也做不成。

来信请写明你的操作系统，CPU架构，web服务器，uWSGI版本，uWSGI命令行配置选项或者是命令行配置内容。

写明你的配置文件选项对于我们查找问题非常有帮助，或者是你自己重新安装一遍或者是重新配置一遍。

官网：

uWSGI性能很高，不要怀疑他的性能。

用了uWSGI，我们的应用程序是否运行的更快？

这不大可能，Web应用程序运行性能的最大瓶颈是应用程序本身。如果想要更快的环境，优化代码或使用缓存或集群之类的技术。我们这样说uWSGI快是指他在处理信息的时候引用了一个很小的信息头在信息处理和调度结构上。

uWSGI在配置的时候对性能和稳定性影响最关键的参数是什么？

uWSGI默认配置已经很好了，如果你想性能更疯狂，可以调下优。

1. 增加或减少延时时间
2. 增加线程功能，如果你不需要的话，最好别开启多线程。
3. 如果你只运行一个app，最好别开启多个解释器。
4. 在生产环境中一定要开启主进程，看的进程管理使用那一章节。
5. 增加works进程数并不一定能增加性能，这还得看你的机器性能，IO绑定，CPU性能等。

为什么不简单的使用HTTP协议

一个最简单的答案就是：HTTP解析速度慢，非常慢。Web服务器已经解析了http协议，而且已经有性能很高的http服务器，我们没必要再解析开发一次，的uWSGI协议是非常简单的解析一个机器，而HTTP是解析一个人很容易。当人类被用作服务器，我们将放弃uWSGI协议在HTTP协议支持。所有这一切说，你可以用uWSGI通过本地HTTP的支持，FastCGI和ZeroMQ 也是如此。

uWSGI为什么支持多种配置方式：

uWSGI试图给工程师尽可能多的选择，以使用各种各样的环境，因为很多基础设施环境已经搭好了，拥有多种配置方法只是我们实现这一目标的一种方式。

uwsgi支持多种服务器，他自己也可以作为http服务器简单的解析HTTP请求

1 首先nginx 是对外的服务接口，外部浏览器通过url访问nginx,

2nginx 接收到浏览器发送过来的http请求，将包进行解析，分析url，如果是静态文件请求就直接访问用户给nginx配置的静态文件目录，直接返回用户请求的静态文件，

  如果不是静态文件，而是一个动态的请求，那么nginx就将请求转发给uwsgi,uwsgi 接收到请求之后将包进行处理，处理成wsgi可以接受的格式，并发给wsgi,wsgi 根据请求调用应用程序的某个文件，某个文件的某个函数，最后处理完将返回值再次交给wsgi,wsgi将返回值进行打包，打包成uwsgi能够接收的格式，uwsgi接收wsgi 发送的请求，并转发给nginx,nginx最终将返回值返回给浏览器。

3要知道第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程，但是要考虑到某些情况

  1 安全问题，程序不能直接被浏览器访问到，而是通过nginx,nginx只开放某个接口，uwsgi本身是内网接口，这样运维人员在nginx上加上安全性的限制，可以达到保护程序的作用。

  2负载均衡问题，一个uwsgi很可能不够用，即使开了多个work也是不行，毕竟一台机器的cpu和内存都是有限的，有了nginx做代理，一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。

  3静态文件问题，用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为，而且他们本身对文件的处理也不如nginx好，所以整个静态文件的处理都直接由nginx完成，静态文件的访问完全不去经过uwsgi以及其后面的东西。