从自已的使用经验、以及归纳、总结网上各类关于Nginx的文章，个人觉得Nginx最擅长的是对静态内容提供HTTP服务，以及Session管理（HTTP任务管理）。Nginx使用了epoll的模式来管理TCP session，所以，性能高，系统资源消耗低。

实事上，Nginx提供动态内容需要通过FastCGI方式（也支持内置的对perl的支持），当觉得Nginx慢时，实际上是FastCGI慢（而FastCGI慢，大多数时候，又是因为数据库读写慢—-高并发的请求导致的阻塞属于不常见的原因之一，比如在遭遇DDos攻击的时候）。

大量的并发FastCGI请求，会使FastCGI管理器应接不暇（暂不去管后台数据库的因素，我们要解决的是FastCGI任务调度慢的情况），从而引起阻塞，引发系统上的“撞车效应”。所以瓶颈在FastCGI处理。

不少关于使用Nginx做负载均衡的例子，实际上就是利用Nginx的 session 管理能力。将处理较慢、花时间较多的FastCGI处理任务分发到多台系统上，这样可以提高系统的负载能力，提高系统发生阻塞的阈值。

Nginx的upstream模块，对“负载均衡”提供了良好的支持，详见：

http://wiki.nginx.org/NginxHttpUpstreamModule

例：
upstream app_group1 {
server 192.168.1.111:9000 weight=5 ;
server 192.168.1.112:9000 weight=5 ;
server 192.168.1.113:9000 weight=3 ;
server 192.168.1.114:9000 weight=5 ;
}

…………

location ~ \.php$ {
fastcgi_pass   app_group_01;
fastcgi_index  index.php;
fastcgi_param  SCRIPT_FILENAME  $fastcgi_script_name;
include        extra/fastcgi_params.conf;
}

之前，是将Nginx分别放在四台FastCGI服务器上，然后使用LVS来作负载调度，运行良好。为了给系统构架分层，使架构清晰，更易于管理和扩展，降低维护难度，试着使用Nginx来调度负载。

一个较明显的效果是四个FastCGI的系统负载下降（原来有Nginx运行在同一系统上）。

Nginx系统的负载很低，活动连接1.7k左右，负载系统不超过1，用掉不到50M的物理内存。相对于LVS复杂的实施以及背后的管理成本，Nginx在低于100M流量的应用中相当有优势。