本文主要介绍如何通过对页面进行压缩从而节省网站的带宽以及提升用户的访问速度。

网站的访问速度是由多个因素所共同决定的，这些因素例如应用程序的响应速度、网络带宽、服务器性能、与客户端之间的网络传输速度等等。其中最重要的一个因素是应用程序本身的响应速度，因此当你为网站性能所苦恼时，你第一个需要着手进行处理的便是尽可能的提升应用程序的执行速度，你可以使用缓存或者是优化代码的执行效率来提升应用程序的速度。

但是，本文并不是介绍如何来提升应用程序的执行效率，前面提到的只不过是为了防止您病急乱投医。在确保您的应用程序的性能已经达到足够好，同时服务器的性能也完全满足的情况下，不妨来试试网页压缩来进一步提升网页的浏览速度，而且非常重要的是，它完全不需要任何的成本，只不过是会让您的服务器CPU 占用率稍微提升一两个百分点而已或者更少。

网页压缩是一项由 WEB 服务器和浏览器之间共同遵守的协议，也就是说 WEB 服务器和浏览器都必须支持该技术，所幸的是现在流行的浏览器都是支持的，包括 IE、FireFox、Opera 等；服务器有 Apache 和 IIS 等。双方的协商过程如下：

   1. 首先浏览器请求某个 URL 地址，并在请求的头 (head) 中设置属性 accept-encoding 值为 gzip, deflate，表明浏览器支持 gzip 和 deflate 这两种压缩方式（事实上 deflate 也是使用 gzip 压缩协议，下面我们会介绍二者之间的区别）；
   2. WEB 服务器接收到请求后判断浏览器是否支持压缩，如果支持就传送压缩后的响应内容，否则传送不经过压缩的内容；
   3. 浏览器获取响应内容后，判断内容是否被压缩，如果是则解压缩，然后显示响应页面的内容。

在实际的应用中我们发现压缩的比率往往在 3 到 10 倍，也就是本来 50k 大小的页面，采用压缩后实际传输的内容大小只有 5 至 15k 大小，这可以大大节省服务器的网络带宽，同时如果应用程序的响应足够快时，网站的速度瓶颈就转到了网络的传输速度上，因此内容压缩后就可以大大的提升页面的浏览速度。

接下来我们介绍几种常用的环境下如何启用网页压缩功能。

纯 Tomcat 服务器

如果您的 WEB 应用程序是跑在 Tomcat 服务器下的，而且直接使用 Tomcat 所提供的 HTTP 服务，那建议你马上动手，因为实在是太简单了，你只需要在 server.xml 配置文件中给 HTTP Connector 增加一个 compression 的参数值为 on 并重启 Tomcat 服务器就立刻生效，配置如下：

    <Connector port=”8080″ protocol=”HTTP/1.1″
               maxThreads=”150″ connectionTimeout=”20000″
               redirectPort=”8443″ compression=”on”/>

Tomcat 采用的是 HTTP/1.1 的 GZIP 压缩协议，它会根据浏览器送过来的请求中的 accept-encoding 值是否包含 gzip 来判断浏览器是否支持 gzip 压缩协议，如果浏览器支持就启用 gzip 压缩，否则就不进行任何压缩处理。Tomcat 中还有另外一个参数 compressableMimeType，这个参数可以用来指定压缩哪种类型的内容，例如可以指定该配置值为：text/html,text /plain ，则只压缩 contentType 为 text/html 和 text/plain 的页面，不过您最好也将 css 和 javascript 文件也算在压缩的文件类型中，因为这两者的压缩效果也十分的明显。

    回页首

Apache 服务器

在 apache 1.3 版本，大家常用 mod_gzip 对输出内容进行压缩，现在主流的浏览器都支持 gzip 解压缩。在 apache2 下，这个模块换名为 mod_deflate，对应的模块文件名是 mod_deflate.so。mod_gzip 本文不做介绍，下面描述一下在 Apache 2 下如何启用并配置 mod_deflate 模块。默认安装的 Apache 不管是 Windows 还是 Linux/Unix，都是不启用该模块的， Linux/Unix 下甚至不带该模块，你需要手工编译这个模块。

下面我们分别介绍在 Windows 和 Linux 操作系统下如何启用并配置 mod_deflate 模块。

在 Windows 下采用安装程序安装的 Apache 服务器已经带有 deflate 所需要的模块 mod_deflate.so 和 mod_headers.so，我们只需要在 httpd.conf 配置文件中启用并进行相关的配置即可，配置如下：

LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
<Location />
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems…
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won’t work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Don’t compress images
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don’t deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>

而如果是 Linux/Unix 操作系统，如果你没有在编译安装的过程中将所需要的两个模块 mod_deflate 和 mod_headers 编译进去的话，那就稍微有点麻烦，首先我们先看如何在编译安装 Apache 过程中也同时编译这两个模块，请在执行 configure 程序时增加两个参数分别是：

# ./configure –enable-deflate –enable-headers

这样在编译完 Apache 后就可以直接在 httpd.conf 中启用并配置 deflate 模块了，配置的方法跟 Windows 平台下是相同的。

如果说您的 Apache 已经在运行了，不想再重新编译一次，那也可以选择只编译 deflate 模块所需的文件 mod_deflate.c 和 mod_headers.c。这两个文件位于 {apache-src}/modules/filters/ 目录下（其中 {apache-src} 为 apache 源文件所在的目录）。使用如下命令来单独编译这两个源文件。

# {apache-bin}/apxs -i -a -c {apache-src}/modules/filters/mod_deflate.c
# {apache-bin}/apxs –i –a –c {apache-src}/modules/filters/mod_headers.c

其中 {apache-bin} 为 Apache 安装目录下的 bin 目录，接下来在 httpd.conf 直接配置该模块即可。

很多时候你在单独编译 deflate 模块的时候可能会碰到编译错误，提示是：

Cannot load /opt/apache/modules/mod_deflate.so into server: /opt/apache/modules/mod_deflate.so: undefined symbol: deflate

解决的方法如下：

编辑 /usr/local/apache2/bin/apr-config 文件修改其中的 LDFLAGS 值为 “-lz”，然后再重新编译 mod_deflate 模块，apxs -ica mod_deflate.c 即可。

为了省却不必要的麻烦，请尽量在编译安装时直接加上 –enable-deflate –enable-headers 参数。

我的实施内容:

#run cmd add mod to apache
/infowarelab/apache2/bin/apxs -i -a -c /infowarelab/src/httpd-2.2.3/modules/filters/mod_deflate.c
/infowarelab/apache2/bin/apxs -i -a -c /infowarelab/src/httpd-2.2.3/modules/metadata/mod_headers.c

#add conf in httpd.conf

<IfModule mod_deflate.c>
 DeflateCompressionLevel 7
 AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript text/css application/x-httpd-php
 AddOutputFilter DEFLATE css js
</IfModule>

参考文档:
http://www.ibm.com/developerworks/cn/web/wa-lo-webcompress/
http://www.hbcms.org.cn/cms/9d/1322.html

Optimal mod_jk configuration

There are many potential problems associated with the default configuration of mod_jk.  Let’s say it is perfectly adequate for a very low traffic website, but when pushing any moderate to high load to mod_jk, there will be connection problems.  This is not due to any bug in mod_jk whatsoever, however, it is because the default configuration makes no assumption about your existing hardware or potential load, so, therefore, it is not tuned accordingly.

Note that the configuration recommendations here are optimal as a base configuration to avoid many of the common problems users experience with mod_jk. There exist many other useful optimizations, but these depend on the environment and web application in use. See http://tomcat.apache.org/connectors-doc/reference/workers.html for details on all available mod_jk properties.

Let’s take a look at a typical default configuration for Apache/Tomcat/mod_jk:
workers.properties

worker.list=loadbalancer,status

worker.node1.port=8009
worker.node1.host=node1.mydomain.com
worker.node1.type=ajp13
worker.node1.lbfactor=1

worker.node2.port=8009
worker.node2.host= node2.mydomain.com
worker.node2.type=ajp13
worker.node2.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2

worker.status.type=status

 
JBoss Web’s (Tomcat) server.xml AJP snippet:

<Connector port=”8009″ address=”${jboss.bind.address}” protocol=”AJP/1.3″
         emptySessionPath=”true” enableLookups=”false” redirectPort=”8443″ ></Connector>

 
Apache’s httpd.conf:

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

The above configuration, under load, may cause mod_jk to be very slow and unresponsive, cause http errors, and cause half-closed connections.   These problems can arise because there are no connection timeouts specified to take care of orphaned connections, no error handling properties defined in workers.properties, and no connection limits set in Apache and Tomcat.

First off, lets take care of Tomcat:

 
Configuring server.xml:

The main concern with server.xml is setting the connectionTimeout which

sets the SO_TIMEOUT of the underlying socket.  So when a connection in

Tomcat hasn’t had a request in the amount of time specified by

connectionTimeout, then the connection dies off.  This is necessary because if the connection hasn’t been used for a certain period of

time then there is the chance that it is half-close on the mod_jk end.

If the connection isn’t closed there will be an inflation of threads

which can over time hit the maxThreads count in Tomcat then Tomcat will

not be able to accept any new connections.  A connectionTimeout of 600000 (10 minutes) is a good number to start out with.  There may be a situation where the connections are not being recycled fast enough, in this instance the connectionTimeout could be lowered to 60000 or 1 minute.

When setting connectionTimeout in Tomcat, mod_jk should also have

connect_timeout/prepost_timeout set, which allows detection that the

Tomcat connection has been closed and preventing a retry request.

The recommended value of maxThreads is 200 per CPU, so here we assume the server is a single core machine.  If it has been quad core, we could push that value to 800, and more depending on RAM and other machine specs.

<Connector port=”8009″
           address=”${jboss.bind.address}”
           emptySessionPath=”true”
           enableLookups=”false”
           redirectPort=”8443″
           protocol=”AJP/1.3″
           maxThreads=”200″
           connectionTimeout=”600000″></Connector>

 
Configuring workers.properties:

See comments inline.

worker.list=loadbalancer,status

worker.template.port=8009
worker.template.type=ajp13
worker.template.lbfactor=1
worker.template.ping_timeout=1000
#ping_mode was introduced in 1.2.27, if not using 1.2.27 please specify connect_timeout=10000 and prepost_timeout=10000 as an alternative

worker.template.ping_mode=A
worker.template.socket_timeout=10
#It is not necessary to specify connection_pool_timeout if you are running the worker mpm
worker.connection_pool_timeout=600

#Referencing the template worker properties makes the workers.properties shorter and more concise
worker.node1.reference=worker.template
worker.node1.host=192.168.1.2

worker.node2.reference=worker.template
worker.node2.host=192.168.1.3

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2

worker.status.type=status

The key points in the above workers.properties is we’ve added limits for the connections mod_jk makes.  With the base configuration, socket timeouts default to infinite. The other important properties are ping_mode and ping_timeout which handle probing a connection for errors and connection_pool_timeout which must be set to equal server.xml’s connectionTimeout when using the prefork mpm.  When these two values are the same, after a connection has been inactive for x amount of time, the connection in mod_jk and Tomcat will be closed at the same time, preventing a half-closed connection.

 
Configuring Apache

Make note that maxThreads for the AJP connection should coincide with

the MaxClients set in Apache’s httpd.conf.  MaxClients needs to be set

in the correct module in Apache.

This can be determined by running httpd -V:

# httpd -V

Server version: Apache/2.2.3
Server built:   Sep 11 2006 09:43:05
Server’s Module Magic Number: 20051115:3
Server loaded:  APR 1.2.7, APR-Util 1.2.8
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture:   32-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with….
-D APACHE_MPM_DIR=”server/mpm/prefork”
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=”/etc/httpd”
-D SUEXEC_BIN=”/usr/sbin/suexec”
-D DEFAULT_PIDLOG=”logs/httpd.pid”
-D DEFAULT_SCOREBOARD=”logs/apache_runtime_status”
-D DEFAULT_LOCKFILE=”logs/accept.lock”
-D DEFAULT_ERRORLOG=”logs/error_log”
-D AP_TYPES_CONFIG_FILE=”conf/mime.types”
-D SERVER_CONFIG_FILE=”conf/httpd.conf”

Which tells me the Server MPM is Prefork.  This is not always 100% accurate so you should also view the output of /etc/sysconfig/httpd to see if the following line is there: HTTPD=/usr/sbin/httpd.worker.  If it is commented out you are running prefork, otherwise if uncommented worker.

httpd.conf:

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
MaxClients       200
MaxRequestsPerChild  0
</IfModule>

Or if Apache is using worker, it is
<IfModule worker.c>
StartServers         2
MaxClients         200
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>

MaxRequestsPerChild is 0, this is the recommended value when using

mod_jk as mod_jk keeps open persistent connections.  The key values in

the above configuration are MaxClients and MaxRequestsPerChild, the rest

of the values are left as default.  Note that MaxRequestsPerChild is

recommended to be 0 however the value may need to be greater than 0

depending on if Apache is used for other modules also, especially in the

case of resource leakage.

 
Advanced worker-mpm Configuration

To get the most out of your mod_jk setup you should be using Apache’s worker mpm which provides a definite performance improvement over the prefork mpm.  The following section will detail how to configure Apache/mod_jk/Tomcat with the worker mpm and the math behind the configuration.

Let’s start out with the worker mpm configuration

<IfModule mpm_worker_module>

ThreadLimit 100
StartServers 5
MaxClients 1000
MinSpareThreads 100
MaxSpareThreads 1000
ThreadsPerChild 100
MaxRequestsPerChild 0
</IfModule>

The optimal configuration completely depends on the hardware being used and the load requirements.  But a general rule of thumb, keep processes low and thread count high.  To determine the number of processes Apache will use simply divide MaxClients by ThreadPerChild.  So in this case MaxClients (1000) / ThreadsPerChild (100) = Processes (10), so Apache will allocate a maximum of 100 threads per each 10 child processes resulting in a total of 1000 possible clients.

Now to translate this to mod_jk, mod_jk maintains a connection pool for each worker defined in workers.properties.  By default with Apache mod_jk sets connection_pool_size to ThreadsPerChild, so in the above case that would translate to 100, giving 1000 possible connections to JBoss.  This may or may not be desired.

Let’s take a common example, there will be 3 JBoss servers that combined needed to be able to handle 900 concurrent connections

worker.list=loadbalancer,status
 

worker.template.type=ajp13
worker.template.port=8009
worker.template.ping_mode=A
worker.template.connection_pool_size=30
worker.template.socket_timeout=10
worker.template.retries=20
 

worker.node1.reference=worker.template
worker.node1.host=192.168.0.101

worker.node2.reference=worker.template
worker.node2.host=192.168.0.102

worker.node3.reference=worker.template
worker.node3.host=192.168.0.103
 

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2, node3
worker.sticky_session=True

worker.status.type=status

The above configuration tells mod_jk to multiplex 30 connections to the available Apache processes, which is 10 processes.  So that means 30 connections multiplexed over 10 processes gives 300 possible connections to each backend worker.  Furthermore, the total connections able to be used in this configuration from Apache is 900 which means  100 connections will be left over for static content or whatnot.

Next configure maxThreads in each ajp connector to match the above.

Node 1 ajp connector:

<Connector port=”8009″
           address=”${jboss.bind.address}”
           emptySessionPath=”true”
           enableLookups=”false”
           redirectPort=”8443″
           protocol=”AJP/1.3″
           maxThreads=”300″
           connectionTimeout=”600000″></Connector>

Node 2 ajp connector:

<Connector port=”8009″
           address=”${jboss.bind.address}”
           emptySessionPath=”true”
           enableLookups=”false”
           redirectPort=”8443″
           protocol=”AJP/1.3″
           maxThreads=”300″
           connectionTimeout=”600000″></Connector>

Node 3 ajp connector:

<Connector port=”8009″
           address=”${jboss.bind.address}”
           emptySessionPath=”true”
           enableLookups=”false”
           redirectPort=”8443″
           protocol=”AJP/1.3″
           maxThreads=”300″
           connectionTimeout=”600000″></Connector>

Remember when using connectionTimeout which is always recommended, prepost_timeout and connect_timeout also need to be set, which is done.  I’m not showing sticky session configuration, but that covered in the main mod_jk article in using mod_jk with JBoss.

 reference from :http://www.jboss.org/community/docs/DOC-11543

Setting up mod_jk with a firewall:

 
Configuring workers.properties:

# Define list of workers that will be used
# for mapping requests
# The configuration directives are valid
# for the mod_jk version 1.2.18 and later
#
worker.list=loadbalancer,status

# Define Node1
# modify the host as your host IP or DNS name.
worker.node1.port=8009
#Using an IP prevents a DNS lookup
worker.node1.host=192.168.1.2
worker.node1.type=ajp13
worker.node1.lbfactor=1
worker.node1.connect_timeout=10000
worker.node1.prepost_timeout=10000
worker.node1.socket_keepalive=True

# Define Node2
# modify the host as your host IP or DNS name.
worker.node2.port=8009
worker.node2.host=192.168.1.3
worker.node2.type=ajp13
worker.node2.lbfactor=1
worker.node2.connect_timeout=10000
worker.node2.prepost_timeout=10000
worker.node2.socket_keepalive=True

# Load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2

# Status worker for managing load balancer
worker.status.type=status

socket_keepalive=true is the most important setting. connect_timeout and

prepost_timeout are to “work-around” firewalls that

ignore keepalives or close the connection for unknown reasons.

 
Configuring server.xml:

The main concern with server.xml is setting the connectionTimeout which

sets the SO_TIMEOUT of the underlying socket.  So when a connection in

Tomcat hasn’t had a request in the amount of time specified by

connectionTimeout, then the connection dies off.  Why is this a good

thing?…because if the connection hasn’t been used for a certain period of

time then there is the chance that it is half-close on the mod_jk end.

If the connection isn’t closed there will be an inflation of threads

which can over time hit the maxThreads count in Tomcat then Tomcat will

not be able to accept any new connections.

When setting connectionTimeout in Tomcat, mod_jk should also have

connect_timeout/prepost_timeout set, which allows detection that the

Tomcat connection has been closed and preventing a retry request.

<Connector port=”8009″
           address=”${jboss.bind.address}”
           emptySessionPath=”true”
           enableLookups=”false”
           redirectPort=”8443″
           protocol=”AJP/1.3″
           maxThreads=”200″
           connectionTimeout=”60000″></Connector>

 
Configuring Apache

Make note that maxThreads for the AJP connection should coincide with

the MaxClients set in Apache’s httpd.conf.  MaxClients needs to be set

in the correct module in Apache. 

This can be determined by running httpd -V:

# httpd -V

Server version: Apache/2.2.3
Server built:   Sep 11 2006 09:43:05
Server’s Module Magic Number: 20051115:3
Server loaded:  APR 1.2.7, APR-Util 1.2.8
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture:   32-bit
Server MPM:     Prefork
  threaded:     no
    forked:     yes (variable process count)
Server compiled with….
-D APACHE_MPM_DIR=”server/mpm/prefork”
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=”/etc/httpd”
-D SUEXEC_BIN=”/usr/sbin/suexec”
-D DEFAULT_PIDLOG=”logs/httpd.pid”
-D DEFAULT_SCOREBOARD=”logs/apache_runtime_status”
-D DEFAULT_LOCKFILE=”logs/accept.lock”
-D DEFAULT_ERRORLOG=”logs/error_log”
-D AP_TYPES_CONFIG_FILE=”conf/mime.types”
-D SERVER_CONFIG_FILE=”conf/httpd.conf”

Which tells me the Server MPM is Prefork

httpd.conf:

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
MaxClients       200
MaxRequestsPerChild  0
</IfModule>

Or if Apache is using worker, it is
<IfModule worker.c>
StartServers         2
MaxClients         200
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>

MaxRequestsPerChild is 0, this is the recommended value when using

mod_jk as mod_jk keeps open persistent connections.  The key values in

the above configuration are MaxClients and MaxRequestsPerChild, the rest

of the values are left as default.  Note that MaxRequestsPerChild is

recommended to be 0 however the value may need to be greater than 0

depending on if Apache is used for other modules also, especially in the

case of resource leakage.

在centos 4.1/apache2.2.3/openssl0.98
参考:www.viiving.com

步骤1：生成密钥
命令：openssl genrsa 1024 > server.key
说明：这是用128位rsa算法生成密钥，得到server.key文件

步骤2: 生成证书请求
命令：openssl req -new -key server.key > server.csr
说明：这是用步骤1的密钥生成证书请求文件server.csr, 这一步提很多问题，一一输入

步骤2: 生成证书请求
命令：openssl req -x509 -days 365 -key server.key -in server.csr > server.crt
说明：这是用步骤1,2的的密钥和证书请求生成证书server.crt，-days参数指明证书有效期，单位为天

把得到的server.key和server.crt文件拷贝到apache的对应目录

然后修改httpd.conf和httpd-ssl.conf两个文件中的配置就可以了.
在开发和测试过程中使用还是不错的.

RoR的部署方式从架构上来说分为前端和后端：

一、前端
前端的作用就是处理静态资源，将动态请求分发到后端，有时候也带有一些额外的功能，例如对特定URL进行rewrite和redirect，对HTTP输出进行gzip压缩等等。

前端目前已知的可以选择apache, lighttpd, litespeed, nginx, haproxy

1、apache2.2
apache是全球市场占有率最高的web server，超过全球互联网网站50%的网站都用apache。apache2.2 + mod_proxy_balancer是一个非常流行，非常稳定的方案。

使用apache2.2唯一的问题就是apache的性能和后面那些轻量级web server相比，差太远了。一方面在处理静态请求方面apache要比lighttpd慢3-5倍，内存消耗和CPU消耗也高出一个数量级，另一方面 mod_proxy_balancer的分发性能也不高，比haproxy差很远。

2、lighttpd
lighttpd是一个轻量级高性能web server，一个在MySQL Inc工作的德国人写的。性能很好，内存和CPU资源消耗很低，支持绝大多数apache的功能，是apache的绝好替代者。目前lighttpd已经 上升到全球互联网第四大web server，市场占有率仅此于apache，IIS和Sun。

lighttpd唯一的问题是proxy功能不完善，因此不适合搭配mongrel来使用。lighttpd下一个版本1.5.0的proxy模块重写过了，将会解决这个问题。

3、litespeed
和lighttpd差不多，商业产品，收费的。比lighttpd来说，多一个web管理界面，不用写配置文件了。litespeed专门为单机 运行的RoR开发了一个lsapi协议，号称性能最好，比httpd和fcgi都要好。他的proxy功能比lighttpd完善。

litespeed的缺点我却认为恰恰是这个lsapi。因为lsapi不是web server启动的时候启动固定数目的ruby进程，而是根据请求繁忙程度，动态创建和销毁ruby进程，貌似节省资源，实则和apache2.2进程模 型一样，留下很大的黑客攻击漏洞。只要黑客瞬时发起大量动态请求，就会让服务器忙于创建ruby进程而导致CPU资源耗尽，失去响应。

当然，litespeed也支持httpd和fcgi，这个和lighttpd用法一样的，到没有这种问题。

4、nginx
一个俄国人开发的轻量级高性能web server，特点是做proxy性能很好，因此被推荐取代apache2.2的mod_proxy_balancer，来和mongrel cluster搭配。其他方面和lighttpd到差不多。

要说缺点，可能就是发展的时间比较短，至今没有正式版本，还是beta版。没有经过足够网站的验证。

5、haproxy
就是一个纯粹的高性能proxy，不处理静态资源的，所有请求统统分发到后端。

二、后端
后端就是跑ruby进程，处理RoR动态请求了。运行后端ruby进程有两种方式：

1、fcgi方式
准确的说，不能叫做fcgi方式，其实就是启动一个ruby进程，让这个ruby进程监听一个tcp/unix socket，以fcgi协议和前端通讯。所以fcgi不是指ruby进程的运行方式，而是ruby进程使用的通讯协议。这就好比你tomcat可以用 http，ajp通讯一样，tomcat自己的运行方式都一样的，只是通讯方式不一样。

fcgi方式启动ruby进程，可以使用lighttpd带的一个spawn-fcgi工具来启动(JavaEye目前采用这种方式)。

值得一提的是，apache2.2的mod_fastcgi的方式也上面还不太一样，由apache动态创建fcgi进程和管理fcgi进程，这 种方式和litespeed的lsapi面临的问题是一样的，此外apache的mod_fastcgi自己也有很多严重的bug，是一种很糟糕的部署方 式。这种糟糕的部署方式也败坏了fcgi的名声。

fastcgi只是一种协议，虽然古老，但并不是不好用，http协议也很古老。没有必要因为apache的mod_fastcgi的运行方式的问题而连带把fastcgi都一同否定了。

2、http方式
也就是用mongrel去跑ruby进程，由于mongrel实际上已经是一个简单的http server，所以也可以单独作为web server使用。mongrel现在越来越受欢迎了。

用fcgi方式还是http方式，我个人觉得区别不大，关键还是看应用的场合，一般而言，推荐的搭配是：

lighttpd ＋ fcgi 或者 nginx ＋mongrel，而apache因为性能差距，而不被推荐。

JavaEye为什么用lighttpd ＋ fcgi呢？原因如下：

1) lighttpd发展了好几年了，市场占有率也相当高，是一个经过实践检验的server，它的文档也很全；而nginx还没有经过足够的市场检验，文档也很缺乏
2) JavaEye的ruby进程和web server在一台机器上面跑，通过unix socket使用fcgi协议通讯可以避免tcp的网络开销，其通讯速度比使用tcp socket使用http协议通讯要快一些。

什么场合使用haproxy？

大规模部署，例如你的RoR应用到十几台服务器上面去，你用haproxy会更好，可以方便的添加删除应用服务器节点，proxy性能更好。

　　Apache 2.0在性能上的改善最吸引人。在支持POSIX线程的Unix系统上，Apache可以通过不同的MPM运行在一种多进程与多线程相 混合的模式下，增强部分配置的可扩充性能。相比于Apache 1.3，2.0版本做了大量的优化来提升处理能力和可伸缩性，并且大多数改进在默认状态下 即可生效。但是在编译和运行时刻，2.0也有许多可以显著提高性能的选择。本文不想叙述那些以功能换取速度的指令，如HostnameLookups等， 而只是说明在2.0中影响性能的最核心特性：MPM（Multi -Processing Modules，多道处理模块）的基本工作原理和配置指令。

其它更详细的写以到http://httpd.apache.org/docs-2.0/

以前都是通过mod_jk来使用apache+tomcat.

今天在晚上看到最新的Apache2.2.4正式发布了proxy功能,于是就进行了一下测试.结果还不错,比mod_jk配置要方便多了.

测试情况:

系统:winxp sp2 apache2.2.4 tomcat 5.0

配置:

1.修改apache的httpd.conf文件,启用proxy,如下:

#########################################################
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#########################################################

2.在httpd.conf中启用vhost配置

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

3.在httpd-vhost.conf配置一个虚拟主机,如下:

ServerAdmin admin@viiving.com
    ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/
ServerName localhost
ServerAlias test.viiving.com
ErrorLog logs/dummy-host3.www.viiving.com-error_log
CustomLog logs/dummy-host3.www.viiving.com-access_log common
>4.启动tomcat和apache在浏览器中输入http://localhost/index.jsp连接地址就可以访问到tomcat中的内容.