apache - 使用Apache2(或Nginx)处理Http请求。是否为每个或一组N个请求创建一个新进程？

Question

web服务器（ws）（比如apache2或nginix（或者tomcat（tc））是否会创建一个新进程来处理传入的请求。我关心的是支持大量并行用户（比如20k+并行用户）的服务器。
我认为负载平衡发生在web服务器的另一端（如果它用于前置tomcat等）。因此，理论上，一个web服务器应该接受所有（20k+）传入的请求，然后才能将负载分配给支持它的其他服务器。
所以，问题是：web服务器（ws）是在一个进程中处理所有这些请求，还是巧妙地生成其他进程来帮助共享工作（我知道“client-server”绑定是通过-client-host:random-port+server-host:fixed-port实现的）。
参考：在阅读这篇文章之前：Fronting Tomcat with Apache我认为这是一个完成所有智能工作的单一过程。但是在本文中提到了mpm（多处理模块）
它结合了两个世界中最好的，有一组子进程，每个进程都有一组独立的线程。有些站点正在使用此技术运行10K+并发连接。
而且，随着线程也像上面提到的那样被生成，它变得越来越复杂。（这些不是通过调用服务方法来为每个单独的请求提供服务的tomcat线程，而是apache ws上处理请求并将它们分发给节点进行处理的线程）。
如果有人用MPM。对所有这些工作原理几乎没有进一步的解释。
像这样的问题-
（1）当子进程生成时，它的确切角色是什么。子进程只是为了调解对tomcat或其他任何东西的请求。如果是，那么在子进程从tc获得响应之后，子进程是否将响应转发给父进程或直接转发给客户机（因为它可以从父进程知道客户机主机：random_port）。我不确定在理论上是否允许这样做，尽管子进程不能接受任何新的请求，因为只能绑定到一个进程的固定端口已经绑定到父进程。
（2）子进程或父进程共享给线程的负载类型。同样，它必须与（1）中的几乎相同。但我不确定的是，即使在理论上，线程是否可以直接向客户机发送请求。

Answer 1

apache历史上使用预处理模型。在这个模型中，每个请求=单独的操作系统（OS）进程。它之所以调用“prefork”，是因为apache在内部派生了一些备用进程和进程请求。如果预处理进程的数量不够-apache fork new。优点：进程可以执行其他模块或进程，而不必在意它们的执行情况；缺点：每个请求都是一个进程，使用的内存太多，os fork也可能对您的请求很慢。
apache-worker MPM的其他模型。与prefork几乎相同，但使用的不是os进程而是os线程。线程-这就像轻量级进程。一个操作系统进程可以使用一个内存空间运行多个线程。worker-mpm使用的内存更少，创建的新线程也更快。缺点：模块需要支持线程，模块崩溃会导致所有操作系统进程的所有线程崩溃（但这对您来说并不重要，因为您只使用apache作为反向代理）。其他缺点：在线程之间切换时CPUswitching context。
所以是的，在你的情况下，工作比工作前好多了，但是…
但是我们有nginx:）nginx使用其他模型（顺便说一下，apache也有事件mpm）。在这种情况下，您只有一个进程（好吧，可以是几个进程，见下文）。工作原理。新的请求上升特殊事件，操作系统进程唤醒，接收请求，准备应答，写应答和去睡眠。
你可以说“哇，但这不是一心多用”，这是对的。但是这个模型和简单的顺序请求处理有一个很大的区别。如果你需要写大数据来减缓客户端的速度，会发生什么？以同步方式，您的进程需要等待确认数据接收，并且只在处理新请求之后。nginx和apache事件模型使用异步模型。nginx告诉操作系统发送一些数据，将这些数据写入操作系统缓冲区，然后…睡着了，或者处理新的请求。当操作系统发送数据时-特殊事件将发送到nginx。所以，主要的区别是nginx不等待i/o（比如connect、read、write），nginx告诉os他想要什么，os向nginx发送事件，而不是这个任务就绪（socket connected、data writed或new data ready to read in local buffer）。此外，现代操作系统可以与hdd（读/写）异步工作，甚至可以将文件从hdd直接发送到tcp套接字。
当然，这个NGIX进程中的所有数学操作都会阻塞这个进程，并停止处理新的和现有的请求。但是，当主要工作流程与网络（反向代理，转发请求到fastcgi或其他后端服务器）加上发送静态文件（也异步）一起工作时，nginx可以在一个os进程中同时服务数千个请求！另外，因为一个os进程（和一个线程）cpu将在一个上下文中执行它。
我之前说过-nginx可以启动几个操作系统进程，每个进程都将由操作系统分配给单独的cpu核心。几乎没有理由分叉更多的nginx操作系统进程（只有一个原因：如果你需要做一些阻塞操作，但简单的反向代理与后端平衡-不是这种情况）
因此，优点是：更少的cpu上下文切换，更少的内存（与工作mpm相比也是如此），快速的连接处理。更多优点：nginx被创建为http负载均衡器，有很多选择（在商业nginx plus中甚至更多）。缺点：如果你在操作系统进程中需要一些硬计算，这个进程将被阻塞（但是你在tomcat中计算的都是，所以nginx只有平衡器）。
注：排版修复将在稍后，过期。另外，我的英语不好，所以修好总是受欢迎的：）
pps：回答关于tc线程数的问题，在评论中提出（太长，不能作为评论发表）：
最好的方法知道它-测试它使用应力加载工具。因为这个数字取决于应用程序配置文件。响应时间不足以帮助回答。因为，例如，200毫秒100%数学（100%CPU限制）与50毫秒数学+150毫秒睡眠等待数据库答案之间的巨大差异。
如果应用程序是100%受CPU限制的—可能每个内核一个线程，但在实际情况下，所有应用程序也会在I/O（接收请求、向客户端发送应答）中花费一些时间。
如果应用程序使用I/O并需要等待来自其他服务（例如数据库）的答案，则此应用程序将在睡眠状态下花费一段时间，并且CPU可以处理其他任务。
所以，创建接近实际负载的请求数并运行压力测试的最佳解决方案是增加并发请求数（当然还有tc工作者的数量）。找到可接受的响应时间并修复此线程数。当然，需要检查之前，它不是数据库故障。
当然，这里我只讨论动态内容，来自磁盘的静态文件请求必须在tomcat之前处理（例如nginx）。