-
Nginx
学习总结
Nginx
概述及注意事项
?
nginx
是一个高性能的
HTTP
和反向代理服务器，
也是一个
IMAP/POP3/SMTP
代理服务
器
。
?
目前
Ng
inx
使
用简单的轮巡（
pollin
g
）算法来实现负载均衡
，所以无法做基本
链接计数的负
载均衡。
?
目前官方
Nginx
并不支持
Windows
，您只能在包括
Linux
< br>、
UNIX
、
BSD
系统下安装和
使用；
?
Nginx
本身只是一个
HTTP
和反向代理服务器，
它无法像
Apache
一样通过安装各种模
块来支持不同的页面脚本，
例如
PHP
、
CGI
等；
?
Nginx
支持简单的负载均衡和容错；
?
支持作为基本
HTTP
服务器的功
能，
例如日志、
压缩、
Byte
ranges
、
Chunked
responses
、
SSL
、虚拟主机等等，应有尽有。
Nginx
优势
?
在高连接并发
的情况下，
Nginx
是
Apac
he
服务
器不错的替代品：
Nginx
在
美国
是
做虚
拟主机生
意的老板们经常选择的软件平台
之一。
能够支持高达
50,000
个并
< br>发连接数的响
应，感谢
Nginx
为我们选择了
epoll and
kqueue
作为开发模型。
?
Nginx
作为
负载均衡服务器
：
Nginx
既可以在内部直接支持
Rails
和
PHP
程序
对外进行服务
，也可以支持作为
HTTP
代理服务器对
外进行服务。<
/p>
Nginx
采用
C
进行编写，不
论是
系统资源
开销还是
CPU
使用
效率都比
< br> Perlbal
要好很多。
?
作为邮件代
理服务器：
Nginx <
/p>
同时也是一个非常优秀的邮
件代理服务器（最早
< br>开发这个产品
的目的之一也是作为邮件代理服
务器），<
/p>
Last. fm
描述了成
功并
且美妙的使用
经验。
?
Nginx
是一个安装非常的简单
，配置文件非常简洁（还能够
支持<
/p>
perl
语法
），
Bugs
非常少的服务器
：
Ngin
x
启动特
别容易，并且几乎可以做到
7*24
不间断运
行，即使运行
数个月
也不需要重新启动。
Nginx
等单
线程服务器设计原理与性能优势
Nginx
是以单线程为基础的，
ng
inx
通过异步
IO
来解决主线程阻塞
的问题。
windows
上有
IOCP
（完成端口，对于一部
IO
包装的比较
多，内部实现时用
cpu
个数的线程进行事件处理，他
会通知你你给定的异步读写已经完成了）
，
li
nux
上有
epool(
一个纯事件通
知接口，他会通
知你可以读或者可以写了
)
，
如果将所有的请求简化为阻塞操作和非阻塞操作问题就简单了，
< br>所有需要阻塞请求的部分全部由
epool
触发相应事件
，
非阻塞
（处理耗时很短）
部分用主线
程一直执行，
直到遇到阻塞部分就停止，
交由阻塞部分监听异步完成事件，
这样就构成了事
件驱动模型
。
很多人认为函数的处理
会阻塞主线程，
事实是他的处理时间占用很短，
做
100
万次
for
循环说不
定比局域网经过一次网络访问的时间还要短，
理解了这点就不难理解了，
如果说你
的服务器每秒钟能处理
1
万个请求，
那么在处理功能函数上
（比如解析协议，
操作、
输出等
等）
顶
多也就占用
0.1-0.3
秒，
剩下的
时间都是耗时在了网络阻塞上，
耗时在了事件发生上
了，
既然如此，
把操作部分独立分出来用多线程执行又有什么意义呢？对于
公网就更不用说
了，网络等
IO
阻塞才
是影响服务器的主要因素，是那块短了的板。
对于网络的
IO
，
IOCP
、
epool
等事件通
知机制就解决了这个问题，
性能上由于是阻
塞的，
所以还不如直接
accept
等快，
但是对于网络延时很严重的情况下性能反而显得更好，
因为他们可以处理大量的
连接而不使性能下降很厉害，如果值直接阻塞能连接处理
1000
个
的话，
epool
等就可以同时处
理
3-5
万个，所以实际的应用价值要大得多。剩下的部分就是
处理事件发生后的事情上面，
我前面的文章已经作了说明，
在此不再重复，
Nginx
、
lighttpd
等都是基于这类模型开发的。
Nginx
连接处理
Ngnix
使用
hash
表
来协助完成请求的快速处理。
考虑到保存键及其值的
hash<
/p>
表存储单
元的大小不至于超出设定参数
(
hash
bucket
size)
，
在启动和每次重新配置时，
Nginx
为
hash
表选择尽可能小的尺寸。直到
hash
表超过参数
(hash
max
size)
的大小才重新进行选择
.
对
于大多数
hash
< br>表都有指令来修改这些参数。例如，保存服务器名字的
hash
< br>表是由指令
server_names_hash_max_size
和
server_names_hash_bucket_size
所控制的。参数
hash
bucket
size
总是等于
hash
表的大小，
并且是一路处理器缓存大小的倍数。在减少了在内
存中的存取次数后，使在处理器中加速
查找
hash
表键值成为可能。如果
h
ash bucket size
等于一路处理器缓存的大小，
那么在查找键的时候，
最坏的情况下在内存中查找的次数为
2<
/p>
。
第一次是确定存储单元的地址，
第二次
是在存储单元中查找键值。
因此，
如果
Nginx
给出需
要增大
hash
max
size
或
hash
bucket
size
的提示，那么首要的是增大前一个参数的大小
< br>.
Nginx
支持如下处理连接的方法（
I/O
复用方法）
，这些方法可以通过
use
指令指定。
?
select-
标准方法。
如果当前平台没有更有效的方法，
它是编译
时默认的方法。
你可以
使用配置参数
-
-with-select_module
和
--without-select_module
来启用或禁用这个
模块。
?
poll-
标准方法。
如果当前平台没有更有效的方法，
它是编译时默
认的方法。
你可以使
用配置参数
--w
ith-poll_module
和
--without-
poll_module
来启用或禁用这个模块。
?
kqueue-
高效的方法，使用于
FreeBSD 4.1+,
OpenBSD 2.9+, NetBSD 2.0
和
MacOS X.
使用双处理器的
MacOS X
系统使
用
kqueue
可能会造成内核崩溃。
?
epoll-
< br>高效的方法，使用于
Linux
内核
2.6
版本及以后的系统。在某些发行版本中，
如
SuSE 8.2,
有让
2.4
版本的内核支持
epoll
的补丁。
?
rtsig-
可执行的实时信号，
使用于
Linux
内核版本
2.2.19
以后的系统。
默认情况下整
个系统中不能出现大于
1024<
/p>
个
POSIX
实时
(
排队
)
信号。这种情况对于高负载
的服务器
来说是低效的；所以有必要通过调节内核参数
/pro
c/sys/kernel/rtsig-max
来增加队
列
的大小。
可是从
Linux
内核版本<
/p>
2.6.6-mm2
开始，
这个参数就不
再使用了，
并且对于
每个进程有一个独立的信号队列，这个队列
的大小可以用
RLIMIT_SIGPENDING
参数调<
/p>
节。当这个队列过于拥塞，
Nginx
就
放弃它并且开始使用
poll
方法来处理连接直到恢
复正常。
?
/dev/poll-
高效的方法，使用于
Solaris
7
11/99+,
HP/UX
11.22+
(eventport),
IRIX
6.5.15+
和
Tru64 UNIX 5.1A+.
?
eventport-
高效的方法，使用于
Solaris
10.
为了防止出现内核崩溃的问题，有必要
安装这个安全补丁。
Nginx
的内存池管理分析
Nginx
的内存管理，主要是用来实现防止内存泄露
，和内存碎片，而并没有真正的预先
分配获得大量内存。
因此实
际上和普通意义上的内存池有一定的区别。
预先分配的内存通常
也就是
1
块
16K
大小的内存快，大内存直接使用
malloc
分配，
16k*n
小内存块中，用来处