nginx文档一
前言
在互联网编程中,http服务器编程作为一个非常重要方向一直为各种语言所重视,从c语言的apache,Lighttpd到当前非常流行的nginx。 Java有tom-cat,jetty,websphere等众多服务器,pyhoen的zope等服务器。既有重量级的服务器,又有轻量级的,嵌入式的服务器。从互联网的应用来说,c语言的http服务器一直占有主导地位,当前最流行的三个开源服务器有apache,Lighttpd和nginx。 Apache作为经典的Web服务器,除了慢没有别的缺点了,Apache2对fcgi支持并不好,非常好用的proxy和proxy_ajp(很多人用它作为tomcat的前端),不支持epoll(这年头,epoll几乎是性能的必备)。Lighttpd作为杀手级的静态文件能力,杀手级的fcgi能力但是proxy模块不够稳定。Nginx速度快,占用资源少,杀手级的proxy和rewrite,非常不错的静态文件能力,最适合作为整个网站的前端服务(将php、svn等不同请求发送往后端apache)。现在国内Nginx的用户越来越多了,多数拥抱Nginx的网站都钟意其优异的性能表现,如果是相对比较大的网站,节约下来的服务器成本无疑是客观的。当前 Ngnix美中不足之处是相关的文档和用户经验都还是很欠缺,用户之间还很难做到可借鉴性的交流。最近因为朋友遇到一些技术问题,我也翻阅了不少 Nginx的邮件列表内容,发现大量的技术细节仍然在频繁变化中,可是中文社区内相关的记录和讨论太少了。相信国内这些Nginx用户积攒的经验肯定是不少的,但可能是因为某些其它因素考虑而看不到相关的技术分享。本书的写作就是为了向大家展示nginx的内部结构,以便于大家更好的使用该服务器。对于一个八万行代码的http服务器,从性能来看它是那么的出色,从功能来看它并不逊色于几十万行的apache服务器。Nginx是实现有几个非常出色的地方:模块化设计,流水线请求处理,多进程控制,epoll的使用,平滑的升级程序或是配置文件。Nginx采用的是单线程的方式,网络服务器的几种模型可以参考C10K的介绍。当然,如果在linux下,最好的模型自然是EPool(effectiveepoll?)。目前一台服务器支持10K个客户访问,基本上还比较麻烦,64位的CPU,可能是一个比较好的解决方案。2块1000M网卡,10K客户端,每个客户端的带宽是 2000/10000=200K,这是理论值,勉强可行。考虑一下纯粹的线程模型。10K个客户端,需要10K个线程。考虑到每个进程3G的用户空间,那么每个线程的空间是3000M/10K=300K,只能说非常勉强可以运行(每个线程的cruntime大约需要2-3K空间)。但是大量的线程调度会极大的减缓系统效率。再考虑一下多个进程的模型,每个进程创建多个线程。其实与纯粹的线程模型差异不大,不过是每个线程的用户空间不受太大限制。大量的线程调度带来的巨大性能损耗会使得整个系统效率及其低下。当然,这种模型也不是一无是处,对于客户端数目不多的情况,比如ftp服务器,这种模型是非常合适的。
然后就剩下epoll模,要使用epoll模型,首先必须有Linux2.6的内核。了解select模型的人都知道,select每个句柄只能支持64个socket,这可以通过阅读linuxselect.h知道。而Poll模型则是一种事件触发的模型,没有64个socket的限制。epoll是对Poll模型的一个改造,让一个Poll句柄可以同时支持多个Socket句柄,好处是将大量Poll句柄的事件探测机制放到内核中处理,大大减少了将数据从内核态拷贝到用户态的次数,从而提高效率。阅读Linux的源码可以看到,epoll的内部使用的是一个Hashmap,Hashmap中存放Poll对象,所以从根本上来说,epoll模型是一种更好的Poll模型(我一直理解为EffectivePoll)。
当然nginx也有不足的地方,例如各个模块之间的耦合性太强,各个模块不适合直接拿出来使用。Nginx的作者过于强调按照他自己所理解的模块化,而把一些基础模块也用作者所谓的模块化来实现,导致代码相互引用太多,艰涩难懂。
本书的编写的面向的用户除了初级linux工程师外,还可以为中高级linux工程师作为开发高性能服务器的工具书,目的除了向用户展示nginx精巧的设计和完整的实现外,还希望通过本书的讲解能够让用户以nginx作为基本框架或是自己实现更多的高性能服务器。
posted on 2012-02-27 16:04 kudosharry 阅读(185) 评论(0) 编辑 收藏 举报