memcached多线程模型 & nginx 多进程模型
2011-11-14 23:37
417 查看
首先分析一下两者的应用场景。
共同点:
两个应用,一个是缓存服务,一个是web服务,都是连接暴多请求频繁,而且对响应时间比较敏感的的应用,在这一点上两者需求一样:大量请求,快速响应。服务端程序基本都这需求,逃也逃不掉。
不同点:
其实是废话,不同点就是一个是cache,一个是web,仔细想想两者的区别还是有点的,就是:不同的请求响应时间相差比较大。什么意思,就是说对于memcached来讲,绝大多数请求服务端处理所花的时间基本是相同的。而nginx就不一样了,一个客户端的请求有的立刻就可以响应,有的则牵涉到php解析,读文件啊什么的,有响应的几个字节,有的则几百K,相差巨大。
共同点:
因为都需要处理高并发的网络IO,所以都采用了异步模式。memcached使用libevent(memcached作者曾把libevent换成libev测了一下,结果性能只提升一点点,考虑到换库的成本,作罢了),而nginx则是自己封装了epoll(linux下)。其实效果是一样的,因为libevent在linux下也是封装了epoll。异步!异步是王道啊!
memcached下的线程关系跟nginx下的进程关系基本是一样的,都是Master-Worker模式。
不同点:
两者最主要的不同点在于连接的监听和分发上,memcached是主线程负责监听和分发,而nginx则是所有的进程都监听,不需要分发。我认为这两种模式恰恰对应了两者应用上的不同点。
对于memcached来说,绝大多数请求要处理的时间相当,所以主线程监听,然后平均分配连接,这样各个线程的负载基本差不多,而且监听连接的效率也高。这样memcached使用多线程而不用多进程也可以减少IPC的成本。而nginx则不一样,请求所需计算时间不定,如果还是简单的RR将连接平均分到各个worker上,可能会造成负载不平均,有的进程比较cpu闲,有的忙死。所以nginx让各个进程争锁来监听,再加上基本的负载处理,这样虽然增加了争锁的成本,但是能基本保证比较闲的进程更有机会接受新连接。nginx的连接处理有点抢占的味道。
其实linux下线程仅仅是默认共享内存的进程而已,仅仅!所以,memcached的线程和nginx的进程在调度上没什么区别。
相关文章推荐
- memcached多线程模型 & nginx 多进程模型
- nginx源码分析--框架设计 & master-worker进程模型
- [nginx] 异步非阻塞多进程模型
- Nginx-进程模型
- nginx 之 多进程模型
- nginx中的进程模型
- nginx源码分析(3)——进程模型
- nginx源码分析--高性能服务器开发 常见进程模型
- nginx多进程模型之热代码平滑升级
- NT KERNEL & SYSTEM 进程占用 80 端口导致 Nginx 启动失败
- Nginx模型 & 惊群问题
- Nginx进程模型和事件模型
- nginx进程模型
- Nginx 之三:nginx服务器模块、web请求处理机制及事件驱动模型、进程功能和进程间通信
- nginx核心进程模型
- nginx多进程模型之配置热加载
- 【nginx】【转】Nginx核心进程模型
- 文章12:初探Nginx架构之进程模型与事件处理机制
- Nginx 进程模型及事件处理机制
- 图解Nginx-Nginx进程模型1