昨天晚上测试了一吧，uwsgi的并发数真的等于进程数的大小，一个耗时长的URL就能能把系统堵死。一些总结，系统的吞吐量=web服务器能处理的并发数*系统的QPS，tomcat通过增加线程数来提高服务器的并发处理能力，优化系统提高响应速度也能提高系统的吞吐量。uwsgi,tomcat,apache,nginx多任务处理器有什么区别，为什么apache,nginx具有多连接处理能力？
网上找到这篇文章： http://www.fmc-modeling.org/category/projects/apache/amp/4_3Multitasking_server.html
inetd传统的架构模式
一个master server来监听端口，然后每个请求fork一个进程来处理：
HTTP是无状态的协议，它只需要响应一个请求,可以“忘记”地关注此事之后，一个HTTP服务器基于inetd架构是效率很低。
4.3.2Apache Multitasking Architectures
所有Apache多任务处理的架构是基于一个任务池体系结构。在启动,Apache创建大量的任务(流程和/或线程),他们中的大多数都是空闲的。一个请求将被处理,通过一个闲置的任务,所以不需要创建一个任务,用于请求处理像4.3.1节中描述inetd。
在以下代码中,preforking架构将被视作第一也是最重要的架构为unix系统。然后我们奉献给你们一组精选的其他Apache多任务处理架构和强调差异有关preforking架构。
4.3.3 The Preforking Multiprocessing Architecture
4.3.3.1. The leader-followers pattern
preforking的架构基于一个池的任务(进程或线程),在三种不同的角色:
- 等待请求(listener)
- 处理一个请求(worker)
- 队列和等待成为侦听器(idle worker)
上图显示了这个系统的结构:侦听器是领袖。只有一个任务可以获准等待连接请求。
如果侦听器请求时,它会处理她，此时他的角色变成worker，如果他处理请求的完成,他将关闭连接,并成为一种闲置工人。这意味着他的排队等待成为侦听器。通常一个闲置的工人的任务将会暂停。
那么这和前面的处理方式有何不同？
首先,一个传入请求将会被立即被listener处理——没有新任务创建。另一方面都应该有一定数量的闲置工人任务以确保总有一个侦听器。其次,不需传递信息的请求重定向到另一个任务,因为listener只是开关。