Web并发模型粗浅探讨V3.pptx
《Web并发模型粗浅探讨V3.pptx》由会员分享,可在线阅读,更多相关《Web并发模型粗浅探讨V3.pptx(60页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、Web并发模型粗浅探讨V3Robbin Fan基本概念并发concurrency并行parallelism吞吐量throughput1 CPU CoreRequest1Request2Request3Request4并发:CPU划分时间片,轮流执行每个请求任务,时间片到期后,换到下一个R1R2R3R4R1R2R3R4R1R2R3R44 CPU CoreRequest1Request2Request3Request4并行:在多核服务器上,每个CPU内核执行一个任务,是真正的并行R1R2R3R4吞吐量单位时间内服务器总的请求处理量以 request/second 来衡量,如1200rps每个请求的
2、处理时间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 buffercodeDBreadcodeDBw
3、ritecodewritebufferIO操作的延时远远高于CPU时钟周期和内存访问,所以一旦Web请求涉及IO操作,CPU处于wait状态,被浪费了IO密集型并发并发真能提高吞吐量吗?假设每个请求执行100ms,顺序执行10个请求共需要1s单核服务器并发处理10个请求,假设平均分配时间片10ms,请求1到请求10将在900ms到1000ms间执行完毕。吞吐量没有任何提高。并发越多,所有请求都变得非常缓慢。(考虑到任务的场景切换开销,吞吐量还会下降,需要超过1s才能执行完毕)。大多数Web型应用都是IO密集型执行请求100ms当中,可能有80ms花在IO上,只有20ms消耗CPU时钟周期,最好
4、情况下,请求1到请求10将在190ms到280ms间执行完毕,吞吐量极大提高。IO密集型应用,大部分CPU花在等待IO上了,所以并发可以有效提高系统的吞吐量R1.R2R10顺序执行10个请求,每个请求100ms,总共1s执行完毕并发执行10个请求,每个请求分配10ms的时间片,仍然1s执行完毕吞吐量没有提高,每个请求处理时间变长R1.R2R10顺序执行10个请求,每个请求100ms,总共1s执行完毕并发执行10个请求,每个请求分配10ms的时间片200ms之后CPU处于空闲状态,190ms到280ms请求全部执行完毕吞吐量得到极大提高IOIOIO并发和并行纯CPU密集型的应用在单核上并发执行多
5、个请求,不能提高吞吐量由于任务来回场景切换的开销,吞吐量反而会下降只有多核并行运算,才能有效提高吞吐量IO密集型的应用由于请求过程中,很多时间都是外部IO操作,CPU在wait状态,所以并发执行可以有效提高系统吞吐量Web并发模型multi-processmulti-threadmulti-process+multi-thread(GIL)event I/Ocoroutinemulti-process常见多进程Web服务端编程模型PHPPythonRuby多进程的管理多进程并发每个进程可以并发处理1个请求,并发能力等于进程数量由操作系统负责进程调度,程序无法控制可以通过操作系统命令影响进程调度
6、优先nice多进程调度例如在一台4核服务器上,运行10个PHP进程。由操作系统负责给某个PHP进程分配某个CPU内核的时间片,实现10个并发处理多进程优点并发模型非常简单,由操作系统调度运行稳定强壮非常容易管理很容易通过操作系统方便的监控,例如每个进程CPU,内存变化状况,甚至可以观测到进程处理什么Web请求很容易通过操作系统管理进程,例如可以通过给进程发送signal,实现各种管理:unicorn隔离性非常好一个进程崩溃不会影响其他进程某进程出现问题的时候,只要杀掉它重启即可,不影响整体服务的可用性很容易实现在线热部署和无缝升级代码兼容性极好,不必考虑线程安全问题多进程可以有效利用多核CPU
7、,实现并行处理多进程的监控手段监控进程CPU top p pid简单处理甚至可以查看进程处理的URL请求监控进程的IO iotop p pid监控进程的物理内存使用 ps,/proc多进程缺点内存消耗大户每个独立进程都需要加载完整的应用环境,内存消耗超大。(COW模式可以缓解这个问题)例如每个Rails进程物理内存占用为150MB,20个workers,则需要3GB物理内存。CPU消耗偏高多进程并发,需要CPU内核在多个进程间频繁切换,而进程的场景切换(context switch)是非常昂贵的,需要大量的内存换页操作。很低的I/O并发处理能力多进程的低IO并发问题多进程的并发能力非常有限每个
8、进程只能并发处理1个请求单台服务器启动的进程数有限,并发处理能力无法有效提高Rails进程消耗内存很大,单台服务器一般启动30个Rails实例PHP FastCGI进程非常轻量级,但单台服务器一般启动64个只适合处理短请求,不适合处理长请求每个请求都能在很短时间内执行完毕,因而不会造成进程被长期阻塞一旦某个操作特别是IO操作阻塞,就会造成进程阻塞,当大面积IO操作阻塞发生,服务器就无法响应了对于无法预知的外部IO操作,应用代码必须设置timeout参数,以防进程阻塞缓解多进程低IO并发问题用nginx做前端Web Server适当增大proxy buffer size,避免多进程request
9、/response buffer IO开销使用X-sendfile,避免多进程读取大文件IO开销凡IO操作都要设置timeout避免无法预知的IO挂起造成进程阻塞编写智能防火墙代码防止劣质爬虫和其他恶意的DOS攻击行为长请求和短请求分离开,不要放在一起多进程spawn静态spawn适合大型应用,稳定处理请求FastCGI(PHP/Ruby)/WSGI(Python)Unicorn(Ruby)动态spawn适合较小型应用,请求伸缩变化大,节省资源Apache module(PHP)Passenger(Ruby/Python)PHP的轻量级进程轻量级进程无虚拟机,无GC,简单解析器,内存管理简单每
10、请求的内存管理模型:每个请求都需要初始化整个框架,请求执行完毕释放所有内存每个进程初始化一般10MB,远远小于Python/RubyPHP的优点每个进程占用内存少,可以多启动一些进程数量,并发处理能力高于Python/Ruby基本没有内存泄露的烦恼即使应用代码有内存泄露问题,每个请求执行完毕,所有内存对象全部释放,基本不会造成严重后果PHP的缺点每请求的内存管理模型造成PHP性能低下每个请求都需要初始化整个应用代码,造成bootstrap速度很缓慢重型PHP框架性能不可避免的低下:例如Drupal性能尤其差,必须依赖多种缓存机制缓解性能问题PHP社区多采用轻量级框架缓解性能问题由于每请求都彻底
11、释放内存,无法实现进程内跨请求共享资源通用数据库连接池内存字典表其他昂贵的需要耗时建立的共享资源PHP的大型应用PHP在大型应用的场景由于PHP的内存模型限制,很多大型应用在较早期就会不可避免的遇到PHP的瓶颈PHP的瓶颈无法解决,必须调整架构,因此在早期就会引入中间应用层(C+,Java),让PHP退化为View层模板语言案例:taobao,facebook,yahoomulti-thread常见多线程模型(1:1)Java VM/.net CLR1 native thread:1 process thread在一个重量级进程当中启动多个线程并发处理请求多线程并发每个线程可以并发处理1个请求
12、,并发能力取决于线程数量线程的调度由VM负责,可以通过编程控制多线程优点多线程并发内存消耗比较少每个线程需要一个thread stack保存线程场景,thread stack一般只需要十几到几十KB内存,不像多进程,每个进程需要加载完整的应用环境,需要分配十几到上百MB内存。线程可以共享资源,特别是可以共享整个应用环境,不必像多进程每个进程要加载应用环境。多线程并发CPU消耗比较小线程的场景切换开销小于进程的场景切换很容易创建和高效利用共享资源数据库线程池字典表,进程内缓存.IO并发能力很高Java VM可以轻松维护几百个并发线程的线程切换开销,远高于多进程单服务器上几十个并发的处理能力可有效
13、利用多核CPU,实现并行运算多线程的缺点VM的内存管理要求超高对内存管理要求非常高,应用代码稍不注意,就会产生OOM(out of memory),需要应用代码长期和内存泄露做斗争GC的策略会影响多线程并发能力和系统吞吐量,需要对GC策略和调优有很好的经验在大内存服务器上的物理内存利用率问题VM内存堆不宜过大,一般2GB为宜。过大的内存堆会造成GC效率下降。在物理内存很多的服务器上为了有效利用更多内存,不得不跑多个Java VM,增加了复杂度。对共享资源的操作对共享资源的操作要非常小心,特别是修改共享资源需要加锁操作,很容易引发死锁问题应用代码和第三方库都必须是线程安全的使用了非线程安全的库会
14、造成各种潜在难以排查的问题单进程多线程模型不方便通过操作系统管理一旦出现线程死锁或者线程阻塞很容易导致整个VM进程挂起失去响应,隔离性很差multi-thread with GILRuby MRI/PythonGlobal Interpreter Lock:有限制的并发执行纯Ruby code的时候mutex.lock,只有一个线程并发,其他线程等待,无法实现并发IO操作或者操作系统调用,释放锁,多线程IO并发由于加锁,无法利用多核,只能使用1个CPU内核,因而无法实现多核并行运算 Why multi-thread(GIL)提供简化的并发策略对CPU密集型运算,并发不能提高吞吐量:加锁,禁止并
15、发对IO密集型运算,并发可以有效提高吞吐量:解锁,允许多线程并发性能对CPU密集型运算,多线程并发由于线程场景切换带来的开销,吞吐量要差于单进程顺序执行兼容性加锁可以保证代码和库的兼容性GC和内存管理Ruby和Python的GC内存管理无法和Java VM相提并论,严重依赖多线程会带来非常严重的内存管理问题MRI multi-thread IO ConcurrencycodeDBreadcodeDBwritecodewritebuffercodeDBreadcodeDBwritecodewritebufferlockrequest1request2codeDBreadcodeDBwriteco
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Web 并发 模型 粗浅 探讨 V3
限制150内