一定会有人认为启用压缩会消耗服务器的CPU及内存资源。就目前的计算机处理能力来讲，这点消耗并不是影响系统负载的“主要矛盾”。相反地，因为启缩，会提高传输效率，从而提高计算机处理请求的速度，从而降低系统负载。

Apache 自带的 mod_deflate 模块，提供了DEFLATE输出过滤器，允许服务器在将输出内容发送到客户端以前进行压缩，以节约带宽。

通常，我们只压缩文本内容，图片文件因为本身已经是压缩格式的，再次压缩的意义不大。

我常用的压缩配置如下：

<Location />
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript
</IfModule>
</Location>

需要注意的是：压缩会于代理服务器造成一定的困扰。比如当我使用Nginx的反向代理+缓存（storage）的时候，存储在Nginx本地的文件是压缩过的（比如 a.css 本来应该是文本文件，存在Nginx本地的是被压缩生成的二进制文件），当用户再次请求时，Ngnix反回给用户的是压缩内容，于是用户这边显示乱码。

另外一个需要注意的问题是：Very 头对缓存命中的影响 http://www.chedong.com/blog/archives/001429.html

参考：
《高性能网站建设指南》
http://www.bsdmap.com/manuals/Apache/mod/mod_deflate.html

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