TOMCAT 配置及性能优化

参考资料：1.http://blog.sina.com.cn/s/blog_4ab26bdd0100gwpk.html
               2.http://blog.163.com/hbxiaoman_yang/blog/static/916313442009227102251604/

1.tomcat 内存参数的管理与设置
   tomcat/bin/catalina.bat
   在rem 的后面增加如下参数
　　set JAVA_OPTS= -Xms256m -Xmx256m -XX:MaxPermSize=64m
2.JDK的设置
   tomcat/bin/catalina.bat
   在最后一个rem后面增加
　　set JAVA_HOME=C:\Program Files\Java\jdk1.6.0
3.虚拟目录的管理
   /tomcat/conf/server.xml
   第一行是以前默认存在的，第二行是新增的

<Context path="" docBase="ROOT" debug="0" reloadable="true"></Context>
 <Context path="/jsp/a" reloadable="true" docBase="D:\workplace\WebContent" />

4.GET方式URL 编码设置
   tomcat/conf/server.xml
   查找下面这部分，在最后增加一段代码就可以了。其中的UTF-8 请根据你的需要自己修改，比如GBK

　　<Connector port="80" maxHttpHeaderSize="8192"
　　.................
　　URIEncoding="UTF-8" useBodyEncodingForURI="true"
　　...............
　　/>

5.虚拟主机配置文件
  tomcat/conf/server.xml

<!-- 默认的主机 -->
　　<Host name="localhost" appBase="webapps"
　　unpackWARs="true"
　　xmlValidation="false" xmlNamespaceAware="false">
　　<Context path="" docBase="ROOT" debug="0" reloadable="true"></Context>
　　...
　　</host>
　　<!-- 以下是新增的虚拟主机 -->
　　<Host name="MyProject" appBase="webapps"
　　unpackWARs="true"
　　xmlValidation="false" xmlNamespaceAware="false">
　　<Context path="" docBase="d:/MyProject" debug="0" reloadable="true"></Context>
　　<!-- 虚拟目录 -->
　　<Context path="/count" docBase="d:/MyProject" debug="0" reloadable="true"></Context>
　　</Host>
　　<Host name="MyProject" appBase="webapps"
　　unpackWARs="true"
　　xmlValidation="false" xmlNamespaceAware="false">
　　<Context path="" docBase="d:/MyProject" debug="0" reloadable="true"></Context>
　　<Context path="/count" docBase="d:/MyProject" debug="0" reloadable="true"></Context>
　　</Host>

6.设置tomcat下的连接数:
   tomcat/conf/server.xml
minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10
maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75
acceptCount：允许的最大连接数，应大于等于maxProcessors，默认值为100
enableLookups：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false
connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。其中和最大连接数相关的参数为maxProcessors和acceptCount。如果要加大并发连接数，应同时加大这两个参数。
web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右,如

<Connector className="org.apache.coyote.tomcat.CoyoteConnector"
port="8080" minProcessors="10" maxProcessors="1024"
enableLookups="false" redirectPort="8080"
acceptCount="1024" debug="0" connectionTimeout="30000" />

7.精简tomcat和其配置文件
#删除不需要的管理应用和帮助应用，提高tomcat安全性。
# 删除webapps下所有文件
# rm –fr $CATALINA_HOME/webapps/*
# 删除server/wenapps下所有文件
# rm –fr $CATALINA_HOME/server/webapps/*
8.精简server.xml
    使用tomcat发布版本中的最小配置文件，提高性能，如果有功能上的需求，在逐个的加入功能配置。
# 备份原来的server.xml为server.xml_bak
# mv server.xml server.xml_bak
# 复制server-minimal.xml为server.xml
# cp server-minimal.xml server.xml
9.web应用的部署
有两个办法可以在系统中部署web服务。
　　1> 拷贝WAR文件或者web应用文件夹（包括该web的所有内容）到$CATALINA_BASE/webapps目录下。
　　2> 为web服务建立一个只包括context内容的XML片断文件，并把该文件放到$CATALINA_BASE/webapps目录下。这个web应用本身可以存储在硬盘上的任何地方。
　　如果有一个WAR文件，想部署它，则只需要把该文件简单的拷贝到CATALINA_BASE/webapps目录下即可，文件必须以“。war”作为扩展名。一旦Tomcat监听到这个文件，它将（缺省的）解开该文件包作为一个子目录，并以WAR文件的文件名作为子目录的名字。接下来，Tomcat 将在内存中建立一个context，就好象在server.xml文件里建立一样。当然，其他必需的内容，将从server.xml中的 DefaultContext获得。
　　部署web应用的另一种方式是写一个Context XML片断文件，然后把该文件拷贝到CATALINA_BASE/webapps目录下。一个Context片断并非一个完整的XML文件，而只是一个 context元素，以及对该应用的相应描述。这种片断文件就像是从server.xml中切取出来的context元素一样，所以这种片断被命名为 “context片断”。
　　举个例子，如果我们想部署一个名叫MyWebApp.war的应用，该应用使用realm作为访问控制方式，我们可以使用下面这个片断：

<!--
　　Context fragment for deploying MyWebApp.war
　　-->
　　<Context path=“/demo” docBase=“webapps/MyWebApp.war”
　　debug=“0” privileged=“true”>
　　<Realm className=“org.apache.catalina.realm.UserDatabaseRealm”
　　resourceName=“UserDatabase”/>
　　</Context>

　　
　　把该片断命名为“MyWebApp.xml”，然后拷贝到CATALINA_BASE/webapps目录下。
　　这种context片断提供了一种便利的方法来部署web应用，不需要编辑server.xml，除非想改变缺省的部署特性，安装一个新的web应用时不需要重启动Tomcat。
10.配置虚拟主机
　关于server.xml中“Host”这个元素，只有在设置虚拟主机的才需要修改。虚拟主机是一种在一个web服务器上服务多个域名的机制，对每个域名而言，都好象独享了整个主机。实际上，大多数的小型商务网站都是采用虚拟主机实现的，这主要是因为虚拟主机能直接连接到Internet并提供相应的带宽，以保障合理的访问响应速度，另外虚拟主机还能提供一个稳定的固定IP。
　　基于名字的虚拟主机可以被建立在任何web服务器上，建立的方法就是通过在域名服务器（DNS）上建立IP地址的别名，并且告诉web服务器把去往不同域名的请求分发到相应的网页目录。
　　在Tomcat中使用虚拟主机，需要设置DNS或主机数据。为了测试，为本地IP设置一个IP别名就足够了，接下来，你需要在server.xml中添加几行内容，如下：

<Server port=“8005” shutdown=“SHUTDOWN” debug=“0”>
　　<Service name=“Tomcat-Standalone”>
　　<Connector className=“org.apache.coyote.tomcat4.CoyoteConnector”
　　port=“8080” minProcessors=“5” maxProcessors=“75”
　　enableLookups=“true” redirectPort=“8443”/>
　　<Connector className=“org.apache.coyote.tomcat4.CoyoteConnector”
　　port=“8443” minProcessors=“5” maxProcessors=“75”
　　acceptCount=“10” debug=“0” scheme=“https” secure=“true”/>
　　<Factory className=“org.apache.coyote.tomcat4.CoyoteServerSocketFactory”
　　clientAuth=“false” protocol=“TLS” />
　　</Connector>
　　<Engine name=“Standalone” defaultHost=“localhost” debug=“0”>
　　<!-- This Host is the default Host -->
　　<Host name=“localhost” debug=“0” appBase=“webapps”
　　unpackWARs=“true” autoDeploy=“true”>
　　<Context path=“” docBase=“ROOT” debug=“0”/>
　　<Context path=“/orders” docBase=“/home/ian/orders” debug=“0”
　　reloadable=“true” crossContext=“true”>
　　</Context>
　　</Host>
　　<!-- This Host is the first “Virtual Host”: www.example.com -->
　　<Host name=“www.example.com” appBase=“/home/example/webapp”>
　　<Context path=“” docBase=“.”/>
　　</Host>
　　</Engine>
　　</Service>
　　</Server>

　Tomcat的server.xml文件，在初始状态下，只包括一个虚拟主机，但是它容易被扩充到支持多个虚拟主机。在前面的例子中展示的是一个简单的 server.xml版本，其中粗体部分就是用于添加一个虚拟主机。每一个Host元素必须包括一个或多个context元素，所包含的context元素中必须有一个是默认的context，这个默认的context的显示路径应该为空（例如，path=“”）。
11.配置基础验证
容器管理验证方法控制着当用户访问受保护的web应用资源时，如何进行用户的身份鉴别。当一个web应用使用了Basic Authentication（BASIC参数在web.xml文件中auto-method元素中设置），而有用户访问受保护的web应用时， Tomcat将通过HTTP Basic Authentication方式，弹出一个对话框，要求用户输入用户名和密码。在这种验证方法中，所有密码将被以64位的编码方式在网络上传输。
　　注意：使用Basic Authentication通过被认为是不安全的，因为它没有强健的加密方法，除非在客户端和服务器端都使用HTTPS或者其他密码加密码方式（比如，在一个虚拟私人网络中）。若没有额外的加密方法，网络管理员将能够截获（或滥用）用户的密码。但是，如果是刚开始使用Tomcat，或者你想在你的 web应用中测试一下基于容器的安全管理，Basic Authentication还是非常易于设置和使用的。只需要添加<security-constraint>和<login- config>两个元素到web应用的web.xml文件中，并且在CATALINA_BASE/conf/tomcat-users.xml 文件中添加适当的<role>和<user>即可，然后重新启动Tomcat。
12.配置单点登录
一旦设置了realm和验证的方法，就需要进行实际的用户登录处理。一般说来，对用户而言登录系统是一件很麻烦的事情，必须尽量减少用户登录验证的次数。作为缺省的情况，当用户第一次请求受保护的资源时，每一个web应用都会要求用户登录。如果运行了多个web应用，并且每个应用都需要进行单独的用户验证，那这看起来就有点像在用户搏斗。用户们不知道怎样才能把多个分离的应用整合成一个单独的系统，所有用户也就不知道他们需要访问多少个不同的应用，只是很迷惑，为什么总要不停的登录。
　　Tomcat 的“single sign-on”特性允许用户在访问同一虚拟主机下所有web应用时，只需登录一次。为了使用这个功能，只需要在Host上添加一个SingleSignOn Valve元素即可，如下所示：
　　<Valve className=“org.apache.catalina.authenticator.SingleSignOn”
　　debug=“0”/>
　　在Tomcat初始安装后，server.xml的注释里面包括SingleSignOn Valve配置的例子，只需要去掉注释，即可使用。那么，任何用户只要登录过一个应用，则对于同一虚拟主机下的所有应用同样有效。
　　使用single sign-on valve有一些重要的限制：
　　1> value必须被配置和嵌套在相同的Host元素里，并且所有需要进行单点验证的web应用（必须通过context元素定义）都位于该Host下。
　　2> 包括共享用户信息的realm必须被设置在同一级Host中或者嵌套之外。
　　3> 不能被context中的realm覆盖。
　　4> 使用单点登录的web应用最好使用一个Tomcat的内置的验证方式（被定义在web.xml中的<auth-method>中），这比自定义的验证方式强，Tomcat内置的的验证方式包括basic、digest、form和client-cert。
　　5> 如果你使用单点登录，还希望集成一个第三方的web应用到你的网站中来，并且这个新的web应用使用它自己的验证方式，而不使用容器管理安全，那你基本上就没招了。用户每次登录原来所有应用时需要登录一次，并且在请求新的第三方应用时还得再登录一次。
　　6> 单点登录需要使用cookies。
13.配置用户定制目录
一些站点允许个别用户在服务器上发布网页。例如，一所大学的学院可能想给每一位学生一个公共区域，或者是一个ISP希望给一些web空间给他的客户，但这又不是虚拟主机。在这种情况下，一个典型的方法就是在用户名前面加一个特殊字符（~），作为每位用户的网站，比如：
　　http://www.cs.myuniversity.edu/~username提供两种方法在主机上映射这些个人网站，主要使用一对特殊的Listener元素。Listener的className属性应该是 org.apache.catalina.startup.UserConfig，userClass属性应该是几个映射类之一。如果电脑系统是 Unix，它将有一个标准的/etc/passwd文件，该文件中的帐号能够被运行中的Tomcat很容易的读取，该文件指定了用户的主目录，使用 PasswdUserDatabase 映射类。
　　http://members.mybigisp.com/~username
　　Tomcat

　　<Listener className=“org.apache.catalina.startup.UserConfig”
　　directoryName=“public_html”
　　userClass=“org.apache.catalina.startup.PasswdUserDatabase”/>

　　web文件需要放置在像/home/users/ian/public_html 或者 /users/jbrittain/public_html一样的目录下面。当然你也可以改变public_html 到其他任何子目录下。
　　实际上，这个用户目录根本不一定需要位于用户主目录下里面。如果你没有一个密码文件，但你又想把一个用户名映射到公共的像/home一样目录的子目录里面，则可以使用HomesUserDatabase类。

<Listener className=“org.apache.catalina.startup.UserConfig”
　　directoryName=“public_html” homeBase=“/home”
　　userClass=“org.apache.catalina.startup.HomesUserDatabase”/>

　　这样一来，web文件就可以位于像/home/ian/public_html 或者 /home/jasonb/public_html一样的目录下。这种形式对Windows而言更加有利，你可以使用一个像c:\home这样的目录。
　　这些Listener元素，如果出现，则必须在Host元素里面，而不能在context元素里面，因为它们都用应用于Host本身。
14.限制特定主机访问
有时，可能想限制对Tomcat web应用的访问，比如，希望只有指定的主机或IP地址可以访问应用。这样一来，就只有那些指定的的客户端可以访问服务的内容了。为了实现这种效果，Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。
　　通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。
　　可以把Admin Web application设置成只允许本地访问，设置如下：

<Context path=“/path/to/secret_files” …>
　　<Valve className=“org.apache.catalina.valves.RemoteAddrValve”
　　allow=“127.0.0.1” deny=“”/>
　　</Context>

　
　　如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。
15.在Tomcat中使用CGI脚本
Tomcat主要是作为Servlet/JSP容器，但它也有许多传统web服务器的性能。支持通用网关接口（Common Gateway Interface，即CGI）就是其中之一，CGI提供一组方法在响应浏览器请求时运行一些扩展程序。CGI之所以被称为通用，是因为它能在大多数程序或脚本中被调用，包括：Perl，Python，awk，Unix shell scripting等，甚至包括Java。不会把一个Java应用程序当作CGI来运行，毕竟这样太过原始。一般而言，开发Servlet总要比CGI具有更好的效率，因为当用户点击一个链接或一个按钮时，不需要从操作系统层开始进行处理。
　　Tomcat包括一个可选的CGI Servlet，允许你运行遗留下来的CGI脚本。
　　为了使Tomcat能够运行CGI，必须做的几件事：
　　1. 把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目录下）改名为servlets-cgi.jar。处理CGI的servlet应该位于Tomcat的CLASSPATH下。
　　2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中，把关于<servlet-name> CGI的那段的注释去掉（默认情况下，该段位于第241行）。
　　3. 同样，在Tomcat的CATALINA_BASE/conf/web.xml文件中，把关于对CGI进行映射的那段的注释去掉（默认情况下，该段位于第299行）。注意，这段内容指定了HTML链接到CGI脚本的访问方式。
　　4. 可以把CGI脚本放置在WEB-INF/cgi 目录下（注意，WEB-INF是一个安全的地方，你可以把一些不想被用户看见或基于安全考虑不想暴露的文件放在此处），或者也可以把CGI脚本放置在 context下的其他目录下，并为CGI Servlet调整cgiPathPrefix初始化参数。这就指定的CGI Servlet的实际位置，且不能与上一步指定的URL重名。
　　5. 重新启动Tomcat，你的CGI就可以运行了。
　　在Tomcat中，CGI程序缺省放置在WEB-INF/cgi目录下，正如前面所提示的那样，WEB-INF目录受保护的，通过客户端的浏览器无法窥探到其中内容，所以对于放置含有密码或其他敏感信息的CGI脚本而言，这是一个非常好的地方。为了兼容其他服务器，尽管你也可以把CGI脚本保存在传统的 /cgi-bin目录，但要知道，在这些目录中的文件有可能被网上好奇的冲浪者看到。另外，在Unix中，请确定运行Tomcat的用户有执行CGI脚本的权限。