Web并发模型粗浅探讨.pptxVIP

Web并发模型粗浅探讨Robbin Fan基本概念并发concurrency并行parallelism吞吐量throughputRequest1Request2Request3Request41 CPU CoreR1R1R1R2R2R2R3R3R3R4R4R4并发：CPU划分时间片，轮流执行每个请求任务，时间片到期后，换到下一个Request2Request3Request4Request14 CPU CoreR1R2R3R4并行：在多核服务器上，每个CPU内核执行一个任务，是真正的并行吞吐量单位时间内服务器总的请求处理量以 request/second 来衡量，如1200rps每个请求的处理时间latency服务器处理请求的并发workers其他因素如GC也会影响吞吐量举例：CSDN new bbs平均每个请求的latency – 200ms总共40个workers理论吞吐量上限 1000/200*40 = 200rps理论每日处理动态请求上限1700万，目前实际每日处理动态请求270-330万，预估实际处理上限600万IO类型磁盘文件操作，例如读硬盘文件操作系统调用，例如shell命令网络操作访问数据库 MySQL, MongoDB, ...访问其他Web服务，发起网络连接访问缓存服务器 Memcached, Redis典型IO密集请求read buffercodeDBreadcodeDBwritecodewritebufferIO操作的延时远远高于CPU时钟周期和内存访问，所以一旦Web请求涉及IO操作，CPU处于wait状态，被浪费了IO密集型并发并发真能提高吞吐量吗？假设每个请求执行100ms，顺序执行10个请求共需要1s单核服务器并发处理10个请求，假设平均分配时间片10ms，请求1到请求10将在900ms到1000ms间执行完毕。吞吐量没有任何提高。并发越多，所有请求都变得非常缓慢。(考虑到任务的场景切换开销，吞吐量还会下降，需要超过1s才能执行完毕)。大多数Web型应用都是IO密集型执行请求100ms当中，可能有80ms花在IO上，只有20ms消耗CPU时钟周期，最好情况下，请求1到请求10将在190ms到280ms间执行完毕，吞吐量极大提高。IO密集型应用，大部分CPU花在等待IO上了，所以并发可以有效提高系统的吞吐量顺序执行10个请求，每个请求100ms，总共1s执行完毕R1R2R10......并发执行10个请求，每个请求分配10ms的时间片，仍然1s执行完毕吞吐量没有提高，每个请求处理时间变长顺序执行10个请求，每个请求100ms，总共1s执行完毕R1R2R10IOIOIO......并发执行10个请求，每个请求分配10ms的时间片200ms之后CPU处于空闲状态，190ms到280ms请求全部执行完毕吞吐量得到极大提高并发和并行纯CPU密集型的应用在单核上并发执行多个请求，不能提高吞吐量由于任务来回场景切换的开销，吞吐量反而会下降只有多核并行运算，才能有效提高吞吐量IO密集型的应用由于请求过程中，很多时间都是外部IO操作，CPU在wait状态，所以并发执行可以有效提高系统吞吐量Web并发模型multi-processmulti-threadmulti-process + multi-thread(GIL)event I/Ocoroutinemulti-process常见多进程Web服务端编程模型PHPPythonRuby多进程的管理多进程并发每个进程可以并发处理1个请求，并发能力等于进程数量由操作系统负责进程调度，程序无法控制可以通过操作系统命令影响进程调度优先nice多进程调度例如在一台4核服务器上，运行10个PHP进程。由操作系统负责给某个PHP进程分配某个CPU内核的时间片，实现10个并发处理多进程优点并发模型非常简单，由操作系统调度运行稳定强壮非常容易管理很容易通过操作系统方便的监控，例如每个进程CPU，内存变化状况，甚至可以观测到进程处理什么Web请求很容易通过操作系统管理进程，例如可以通过给进程发送signal，实现各种管理: unicorn隔离性非常好一个进程崩溃不会影响其他进程某进程出现问题的时候，只要杀掉它重启即可，不影响整体服务的可用性很容易实现在线热部署和无缝升级代码兼容性极好，不必考虑线程安全问题多进程可以有效利用多核CPU，实现并行处理多进程的监控手段监控进程CPU top –p pid简单处理甚至可以查看进程处理的URL请求监控进程的IO iotop –p pid监控进程的物理内存使用 ps, /proc多进程缺点内存消耗大户每个独立进程都需要加载完整的应用环境，内存消耗超大。(COW模式可以缓解这个问题)例如每个Rails进程物理内存占用为150MB，20个worker