Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。您可以选择自己的需要选择不同的操作系统和对应
的JDK的版本（只要是符合Sun发布的Java规范的），但我们推荐您使用Sun公司发布的JDK。确保您所使用的版本是最新的，因为Sun公司和其它
一些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。
可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。
参数
描述
-Xms
JVM初始化堆的大小
-Xmx
JVM堆的最大值
这
两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的
情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须
重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程
序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最
大值设置为可用内存的最大值的80%。
Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。
Windows下，在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下设置：
JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'
需要把这个两个参数值调大。例如：
JAVA_OPTS='-Xms256m -Xmx512m'
表示初始化内存为256MB，可以使用的最大内存为512MB。
另
外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析
实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，
但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小
设大，保证垃圾收集不在整个基准测试的过程中出现。
如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不
超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究
垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80%
作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。
Tomcat 5常用优化和配置
1、JDK内存优化：
Tomcat默认可以使用的内存为128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：
JAVA_OPTS='-Xms[初始化内存大小] -Xmx[可以使用的最大内存]
一般说来，你应该使用物理内存的 80% 作为堆大小。
2、连接器优化：
在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：
maxThreads：
Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值200。
acceptCount：
指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。
minSpareThreads：
Tomcat初始化时创建的线程数。默认值4。
maxSpareThreads：
一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值50。
enableLookups：
是否反查域名，默认值为true。为了提高处理能力，应设置为false
connnectionTimeout：
网络连接超时，默认值60000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
maxKeepAliveRequests：
保持请求数量，默认值100。
bufferSize：
输入流缓冲大小，默认值2048 bytes。
compression：
压缩传输，取值on/off/force，默认值off。
其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。
3、tomcat中如何禁止和允许列目录下的文件
在{tomcat_home}/conf/web.xml中，把listings参数设置成false即可，如下：
<servlet>
...
<init-param>
<param-name>listings</param-name>
<param-value>false</param-value>
</init-param>
...
</servlet>
4、tomcat中如何禁止和允许主机或IP地址访问<Host name="localhost" ...>
...
<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.mycompany.com,www.yourcompany.com"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
deny="192.168.1.*"/>
...
</Host>
如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。
5、容量规划
A. 硬件
采用什么样的硬件体系？需要多少台计算机？使用一个大型的，还是使用多台小型机？每个计算机上使用几个CPU？使用多少
内存？使用什么样的存储设备，I/O的处理速度有什么要求？怎样维护这些计算机？不同的JVM在这些硬件上运行的效果如何（比如IBM
AIX系统只能在其设计的硬件系统上运行）？
B. 网络带宽
带宽的使用极限是多少？web应用程序如何处理过多的请求？
C. 服务端操作系统
采用哪种操作系统作为站点服务器最好？在确定的操作系统上使用哪个JVM最好？例如，JVM在这种系统上是否支持本地多线程，对称多处理？哪种系统可使web服务器更快、更稳定，并且更便宜。是否支持多CPU？
D. Tomcat容量计划
以下介绍针对Tomcat做容量计划的步骤：
1） 量化负载。如果站点已经建立并运行，可以使用前面介绍的工具模仿用户访问，确定资源的需求量。
2） 针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的资源，并与其它请求做比较，这样就确定了系统的瓶颈所在。例如：如果servlet在查询数据库的步骤上耗用较长的时间，那么就需要考虑使用缓冲池来降低响应时间。
3）
确定性能最低标准。例如，你不想让用户花20秒来等待结果页面的返回，也就是说甚至在达到访问量的极限时，用户等待的时间也不能超过20秒种（从点击链接
到看到返第一条返回数据）。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标准，一般最好采取同行中的最低标准或
对这个标准做出评估。
4）
确定如何合理使用底层资源，并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试，
观察是否符合需求。在测试Tomcat时尽量多采用几种JVM，并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达到资源充分合理稳
定地使用的效果，还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的资源配置。这个过程最为复杂，而且一般由于没有可参考的值所以只能靠理论推断和
经验总结。
5） 如果通过第4步的反复测试如果达到了最优的组合，就可以在相同的生产环境上部署产品了。
此外应牢记一定要文档化你的测试过程和结果，因为此后可能还会进行测试，这样就可以拿以前的测试结果做为参考。另外测试过程要反复多次进行，每次的条件可能都不一样，因此只有记录下来才能进行结果比较和最佳条件的选择。
这样我们通过测试找到了最好的组合方式，各种资源得到了合理的配置，系统的性能得到了极大的提升。
