因为你可以呀！ :) uWSGI想要成为一个完整的web应用部署解决方案，包含以下助力：
- :doc:`ProcessManagement`
- Management of long-running tasks
- :doc:`RPC`
- :doc:`Clustering`
- :doc:`LoadBalancing`
- :doc:`Monitoring`
- :doc:`ResourceLimiting`
... 以及许多其他你必须委托给外部脚本和手工系统管理员任务的烦人日常任务。
如果你正为你的WSGI, PSGI或者Rack应用搜寻一个简单的服务器，那么uWSGI可能不适合你。不过，如果你正构建一个应用，它需要坚如磐石、快速、易于分发并且为各种负载进行优化，那么你很可能会发现自己需要uWSGI。
uWSGI最好的定义是“你的网络应用的瑞士军刀”。
uwsgi (全部小写) 是从SCGI衍生而来的，但使用二进制字符串长度表示，以及一个包含var块（16位长）大小的4字节头部，和几个通用字节。我们不重新发明轮子。二进制管理比字符串解析容易且廉价得多，而每一位对我们的项目都是必须的。如果你需要证明，那么看看 :doc:`official protocol documentation<Protocol>` ，你将会明白，为什么需要一个新的协议。显然，你可以随意使用其他支持的协议。记住，如果在某些场景下，你不能使用uWSGI，那么这是一个uWSGI问题。
是哒，这是uWSGI的主要特性之一。你可以将多个实例绑定在不同的服务器上，而使用你的web服务器/代理/路由器的负载均衡功能，你可以分布负载。像 :doc:`RPC` 这样的系统允许你快速调用远端节点的函数，而 :doc:`Legion` 允许你在多节点设置中选出一个master。
理智选择超时时间是高可用性的关键。不要信任那些不允许你选择超时时间的网络应用。
在uWSGI邮件列表上发布一条信息，其中包含你的
- 操作系统版本
- CPU架构
- 使用的web服务器（如果有的话）
- uWSGI版本
- uWSGI命令行或配置文件
你应该添加 --show-config 选项，然后把输出贴到消息中。这对找出uWSGI有啥问题将非常有用。你也可以使用调试符号进行 :doc:`rebuild uWSGI<Build>` ，并且将其运行在诸如 gdb 这样的调试器下。
uWSGI是一个浩大的工程，带有数百个选项。你应该做好准备，并不是所有的东西在第一次使用的时候都是对的。寻求帮助，寻求帮助，以及寻求帮助。如果你感到沮丧，那么不要把时间花在谴责和咆哮上 —— 相反，简单加入邮件列表，然后寻求帮助。它是开源的，如果你只是咆哮，那么只是无用功。
这是一个好问题 :) 但是忧伤的是，没有简单的答案。uWSGI在开发中并未考虑简单性，而是通用性。你可以通过其中一个快速入门来开始，如果有问题，只需在邮件列表，或者IRC频道中寻求帮助。
发送邮件到unbit.it上的info，并在主题中使用单词"uWSGI"。你发送的邮件应该包含你的公司信息以及你的具体要求。我们将尽快答复。
可能不行哦。uWSGI服务器要求一个现代的平台/环境。
抱歉哈，我们只为回归测试进行“官方”基准。如果基准对你非常重要，那么你可以在邮件列表上搜索，自己做基准，或者Google一下。uWSGI赋予机器健康优先权，因此，不要期望你使用不切实际数目的并发连接数的 ab 测试无需调整就能完美进行管理。如果你想要进行有效的基准（并且避免有人在你的博客下咆哮），那么一些socket和网络知识是必须的。还要记得，uWSGI可以在各种模式下运行，因此，如果你不想看起来不可理喻，那么避免把preforking模式下配置的服务器与其他在非阻塞/异步模式下配置的服务器进行对比。
Note
如果你看到你的测试在更高的并发速率下失败了，那么你可能到达了你的OS socket backlog队列限制 (在Linux中最高是128个槽，可以通过 /proc/sys/net/somaxconn 和 /proc/sys/net/ipv4/tcp_max_syn_backlog 对TCP socket进行调整)。
你可以使用 listen 配置选项，在uWSGI中设置这个值。
如前所述，uWSGI不是灵丹妙药，它并不打算让整个世界都喜欢，而显然，它也不是世界上最快的服务器。它就是一个软件，遵循一个你可能不喜欢，又或者爱得要死的问题“解决方法”。使用的方法对于某些情况下会更好，而应该在每个应用自己的优点上进行分析，使用适当而准确的真实世界的基准。
在Unbit，我们在服务器上托管了数百个不可靠的web应用。它们所有都运行在没有限制（内核级别）环境下，其中因为一个实现错误导致的进程阻塞将会导致整个站点挂掉。而harakiri模式有两种操作模式：
- 一个我们定义为“原始，并且有点靠不住”（用于不带进程管理器的简单设置）
- 另一个我们定义为“可靠的”，依赖于uWSGI进程管理器 (见 :doc:`ProcessManagement`)。
第一个在每个请求的开始设置一个简单的告警。如果进程获得 SIGALRM 信号，那么它会终止。我们称其为不可靠的，因为你的应用或者你使用的一些模块可能会通过简单调用 alarm() ，从而覆盖或者简单取消告警。
第二个使用一个master进程共享内存区域 (通过 mmap)，它维护池中每个worker上的统计信息。在每个请求的开始，worker设置一个时间戳，表示过了多久， 进程将在其专用区域被杀死。这个时间戳会在每次成功请求之后清零。如果master进程发现了一个带有过去时间戳的worker，那么它会毫不留情地杀死它。
不可能。web应用部署中的最大瓶颈是应用本身。如果你想要一个更快的环境，那么优化你的代码，或者使用诸如集群、缓存这样的技术。我们之所以说uWSGI快，是因为它引入非常少等待开销到部署结构中。
默认情况下，是用合理的“几乎是会所有”的值来配置uWSGI的。但是如果以及当事情开始变得不可控制的时候，调整是必须的。
- 增加（或减少）超时时间是重要的，修改socket监听队列大小也是如此。
- 考虑线程。如果你不需要线程，那么不要启用它们。
- 如果你只是运行一个应用，那么你可以禁用多解释器。
- 总是记住在生产环境上启用master进程。见 :doc:`ProcessManagement` 。
- 增加worker不是意味着“增加性能”，因此，基于你的应用的性质，为 workers 选项选择一个合适的值 (受IO限制，受CPU限制，IO等待……)
一个好问题，它有一个简单的答案：HTTP解析很慢，真的很慢。为嘛我们应该做一个复杂的任务两次呢？web服务器已经解析请求了！ :doc:`uwsgi protocol<Protocol>` 对机器而言，是非常容易解析的，而HTTP对人类而言，是非常容易解析的。一旦人类被当成服务器使用，我们会放弃uwsgi协议，支持HTTP协议。这就是说，你也可以通过 :doc:`HTTP`, :doc:`FastCGI`, :doc:`ZeroMQ` 和其他协议使用uWSGI。
系统管理是件关于技能和品味的事。uWSGI试图为系统管理员提供尽可能多的选择来与任何已经能用的基础设施集成。拥有多种配置方法只是我们达成此目标的一种方式。