从自已的使用经验、以及归纳、总结网上各类关于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流量的应用中相当有优势。
