如何优化提高tomcat启动速度.docx
- 文档编号:29883591
- 上传时间:2023-08-03
- 格式:DOCX
- 页数:21
- 大小:27.06KB
如何优化提高tomcat启动速度.docx
《如何优化提高tomcat启动速度.docx》由会员分享,可在线阅读,更多相关《如何优化提高tomcat启动速度.docx(21页珍藏版)》请在冰豆网上搜索。
如何优化提高tomcat启动速度
如何优化提高tomcat启动速度
在tomcat启动的时候,我们可以做一些优化设置来使得tomcat的启动更快速,下面是一些常见的优化加速启动的方法建议(以tomcat-7.+为例说明)。
1、 Jars包
1.1、将一些不必要的jar包去掉,当tomcat启动加载jar包的时候,会去搜寻每个jar包里的class文件,这些都会耗费一些时间,如果你把不必要的jar包去掉了,很显然会节省时间。
1.2、你可以将一些与TLDfiles、注解、网络碎片无关的jar包加入到属性
tomcat.util.scan.DefaultJarScanner.jarsToSkip的值中,这可以在conf/catalina.properties中进行设置。
2、 缓存
你可以在bin/catalina.sh中设置jvm所能使用到的缓存大小,如下:
JAVA_OPTS=’-Xms1024m-Xmx1024m’
3、 配置文件
Tomcat的配置比如server.xml是xml文件,而xml的解析也是要花时间的,如果我们能将xml配置文件尽可能地弄得简洁一些,比如去掉一些没有用到的节点,这也有助于减少启动的时间,虽然这个节省的时间看来很少。
4、 应用程序
4.1、确保你程序在启动的时候没有一些处理很耗时的地方。
4.2、删除掉tomcat自带的目录webapps及下面的所有内容,不然的话每次启动的时候都会加载这些自带的例子。
4.3、修改WEB-INF/web.xml文件,在默认的情况下
5、 并行启动多个应用程序
默认情况下,假设在一个tomcat下你有多个应用,那么启动的时候,这些应用程序都是依次启动的,除非所有应用全部启动完毕,tomcat才会启动完成,但从Tomcat7.0.23+开始,你可以配置多个应用程序并行启动了!
你可以通过修改配置文件中Host里面的startStopThreads这个属性的值来达到这个目的,将多个应用startStopThreads的值设为不同即可。
6、 EntropySource
Tomcat7+严重依赖SecureRandom这个类为它的sessionid或其它地方取得随机数值,这取决于你的JRE,它有可能在tomcat启动时造成非常大的耗时,比如,在子猴启动tomcat-7.0.26的时候,它耗时近25秒!
INFO:
CreationofSecureRandominstanceforsessionIDgenerationusing[SHA1PRNG]took[24,790]milliseconds.
要解决这个问题,可以通过配置JRE使用非阻塞的EntropySource,在bin/catalina.sh中加入这么一行:
-Djava.security.egd=file:
/dev/./urandom即可。
1 概述
本文档主要介绍了Tomcat的性能调优的原理和方法。
可作为公司技术人员为客户Tomcat系统调优的技术指南,也可以提供给客户的技术人员作为他们性能调优的指导手册。
2 调优分类
由于Tomcat的运行依赖于JVM,从虚拟机的角度我们把Tomcat的调整分为外部环境调优和自身调优两类来描述。
2.1 外部环境调优
调整Tomcat运行环境的操作系统参数和运行Tomcat的java虚拟机参数。
2.1.1 JAVA虚拟机性能优化
Tomcat需要依赖Java虚拟机运行。
根据客户选用的主机的操作系统选择对应的JDK的版本。
无论哪个厂商的JDK,都建议使用最新的版本。
虚拟机可通过命令行的方式改变虚拟机使用内存的大小。
如下表所示有两个参数用来设置虚拟机使用内存的大小。
参数 描述
-Xms
-Xmx
Tomcat默认可以使用的内存为128MB,在较大型的应用项目中,这点内存是不够的,需要调大。
[LD1]Windows下,在文件tomcat_home/bin/catalina.bat,Unix下,在文件tomcat_home/bin/catalina.sh的前面,增加如下设置:
JAVA_OPTS=‘-Xms【初始化内存大小】-Xmx【可以使用的最大内存】’'
需要把这个两个参数值调大。
例如:
[html]viewplaincopy
JAVA_OPTS='-Xms256m-Xmx512m'
表示初始化内存为256MB,可以使用的最大内存为512MB。
另外需要考虑的是Java提供的垃圾回收机制。
虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。
收集垃圾可以接受的速度与应用有关,应该通过分析实际的垃圾收集的时间和频率来调整。
如果堆的空间很大,那么完全垃圾收集(FULLGC)就会很慢,但是频度会降低。
如果在客户系统中把堆的大小和内存的需要一致,完全收集就很快,但是会更加频繁。
调整堆大小的的目的是最小化垃圾收集的时间,以在特定的时间内最大化处理客户的请求。
对于SUN和HP等虚拟机,推荐将最小堆大小和最大堆大小设置为同一值,因为这样可以避免浪费用于时常调整堆大小所需的VM资源。
当然,客户系统如果用到IBM虚拟机,要特别的注意设置-Xms和-Xmx一样大小会耽误垃圾回收的开始直到堆满,这样第一次垃圾回收就会变成非常昂贵的操作。
推荐把-Xms设置为应用所需的最小值,这样会产生高效的垃圾回收。
2.1.2 操作系统性能优化
以客户系统为HP-UX为例。
HP系统中对Tomcat有影响的参数:
其中:
max_thread_proc:
一个进程所能创建的线程的最大数
nkthread:
在系统上同时允许的核心线程的最大数
maxfiles上表给的建议是不是不合适?
如果在输出里看到消息:
java.lang.OutOfMemoryError:
unabletocreatenewnativethread,则说明名为max_thread_proc的Unix内核设置过小。
max_thread_proc是单个进程中的最大线程数。
它必须大到能够容纳Java应用程序中的所有线程以及虚拟机本身中的部分额外线程。
查看核心参数:
$ulimit-a
显示[LD2]输出中的nofiles是指用户的进程能同时打开的最大文件句柄数。
如果日志中出现”twomanyopenfiles”的异常,需要重点检查这个参数。
coredump参数是core文件最大值的,限制当进程coredump时将产生core文件的大小不能超过这个最大值。
如果在日志文件检查时,发现core文件不完整,需要增大这个参数值。
执行ulimit -n命令可以设置nofiles参数,执行ulimit-c命令设置core文件最大值。
如果是在Windows操作系统上使用Tomcat,那么最好选择服务器版本。
因为在非服务器版本上,最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。
并且基于安全性的考虑,必须经常给操作系统打上最新的补丁。
2.1.3 Tomcat与其它web服务器整合使用
虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把apache和tomcat集成起来,将html与jsp的功能部分进行明确分工,让tomcat只处理jsp部分,其它的由apache,IIS等这些web服务器处理,由此大大节省了tomcat有限的工作线程[LD3]。
2.2 自身调优
本节将说明Tomcat性能调优的技巧和方法,这些技巧和方法与操作系统或Java虚拟机的种类无关。
以下方法都是针对Tomcat性能自身调整的最佳方式。
2.2.1 禁用DNS查询
当web应用程序要记录客户端的信息时,它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。
DNS查询需要占用网络,并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程,这样会消耗一定的时间。
为了消除DNS查询对性能的影响我们可以关闭DNS查询,方式是修改server.xml文件中的enableLookups参数值:
不同的tomcat版本稍有不同。
Tomcat4
[html]viewplaincopy
minProcessors=“5”maxProcessors=“75”enableLookups=“false” redirectPort=“8443”acceptCount=“100”debug=“0”connectionTimeout=“20000” useURIValidationHack=“false”disableUploadTimeout=“true”/> Tomcat5 [html]viewplaincopy maxSpareThreads=“75”enableLookups=“false”redirectPort=“8443” acceptCount=“100”debug=“0”connectionTimeout=“20000” disableUploadTimeout=“true”/> 除非客户需要连接到站点的每个HTTP客户端的机器名,否则我们建议在生产环境上关闭DNS查询功能。 可以通过Tomcat以外的方式来获取机器名。 这样不仅节省了网络带宽、查询时间和内存,而且更小的流量会使日志数据也会变得更少,显而易见也节省了硬盘空间。 对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显。 2.2.2 调整线程数 另外一个可通过应用程序的连接器(Connector)进行性能控制的参数是创建的处理请求的线程数。 Tomcat使用线程池加速响应速度来处理请求。 在Java中线程是程序运行时的路径,是在一个程序中与其它控制线程无关的、能够独立运行的代码段。 它们共享相同的地址空间。 多线程帮助程序员写出CPU最大利用率的高效程序,使空闲时间保持最低,从而接受更多的请求。 Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。 这些值在安装后就已经设定为默认值并且是足够使用的,但是随着站点的扩容而改大这些值。 minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。 也就是说,如果一天内每秒仅发生5次单击事件,并且每个请求任务处理需要1秒钟,那么预先设置线程数为5就足够了。 但在你的站点访问量较大时就需要设置更大的线程数,指定为参数maxProcessors的值。 maxProcessors的值也是有上限的,应防止流量不可控制(或者恶意的服务攻击),从而导致超出了虚拟机使用内存的大小。 如果要加大并发连接数,应同时加大这两个参数。 webserver允许的最大连接数还受制于操作系统的内核参数设置,通常Windows是2000个左右,Linux是1000个左右。 在Tomcat5对这些参数进行了调整,请看下表: 最好的方式是多设置几次并且进行测试,观察响应时间和内存使用情况。 在不同的机器、操作系统或虚拟机组合的情况下可能会不同,而且并不是所有的web站点的流量都是一样的,因此没有一刀切的方案来确定线程数的值。 2.2.3 加速JSP编译速度 当第一次访问一个JSP文件时,它会被转换为Javaservlet源码,接着被编译成Java字节码。 客户工程师可以控制使用哪个编译器,默认情况下,Tomcat使用命令行javac进行使用的编译器。 也可以使用更快的编译器,这里将介绍如何优化它们。 [LD4]另外一种方法是不要把所有的实现都使用JSP页面,而是使用一些不同的java模板引擎变量。 在Tomcat4.0中可以使用流行而且免费的Jikes编译器。 Jikes编译器的速度要高于Sun的Java编译器。 首先要安装Jikes(可访问获得更多的信息),接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。 装好Jikes以后还需要设置让JSP编译servlet使用Jikes,需要修改web.xml文件中jspCompilerPlugin的值: [html]viewplaincopy org.apache.jasper.servlet.JspServlet -- /usr/local/jdk1.3.1-linux/jre/lib/rt.jar: /usr/local/lib/java/servletapi/servlet.jar 在Tomcat4.1(或更高版本),JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。 客户开发人员需要在元素中定义一个名字叫”compiler”,并且在value中有一个支持编译的编译器名字,示例如下: [html]viewplaincopy org.apache.jasper.servlet.JspServlet Ant可用的编译器 由于JSP页面在第一次使用时已经被编译,那么你可能希望在更新新的jsp页面后马上对它进行编译。 实际上,这个过程完全可以自动化,因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。 在Tomcat4的bin目录下有一个名为jspc的脚本。 它仅仅是运行翻译阶段,而不是编译阶段,使用它可以在当前目录生成Java源文件。 它是调试JSP页面的一种有力的手段。 可以通过浏览器访问再确认一下编译的结果。 这样就确保了文件被转换成servlet,被编译了可直接执行。 这样也准确地模仿了真实用户访问JSP页面,可以看到给用户提供的功能。 也抓紧这最后一刻修改出现的bug并且修改它。 Tomcat提供了一种通过请求来编译JSP页面的功能。 客户可以在浏览器地址栏中输入http: //localhost: 8080/examples/jsp/dates/date.jsp? jsp_precompile=true,这样Tomcat就会编译data.jsp而不是执行它。 此举唾手可得,不失为一种检验页面正确性的捷径。 2.2.4 NIO配置 NIO(No-blockingI/O)从JDK1.4起,NIOAPI作为一个基于缓冲区,并能提供非阻塞I/O操作的API被引入[LD6]。 TOMCAT可以支持高并发的企业级应用。 其中有个很大的原因就是,配置良好的tomcat都会使用APR(ApachePortableRuntime),APR是ApacheHTTPServer2.x的核心,它是高度可移植的本地库,它使用高性能的UXINI/O操作,低性能的javaio操作,但是APR对客户开发人员而言可能稍稍有点难度,在很多OS平台上,可能需要重新编译APR。 但是从Tomcat6.0以后,客户开发人员很容易就可以用NIO的技术来提升tomcat的并发处理能力。 但是为什么NIO可以提升tomcat的并发处理能力呢,我们先来看一下java传统io与javaNIO的差别。 Java传统的IO操作都是阻塞式的(blockingI/O),如果有socket的编程基础,你会接触过堵塞socket和非堵塞socket,堵塞socket就是在accept、read、write等IO操作的时候,如果没有可用符合条件的资源,不马上返回,一直等待直到有资源为止。 而非堵塞socket则是在执行select的时候,当没有资源的时候堵塞,当有符合资源的时候,返回一个信号,然后程序就可以执行accept、read、write等操作,一般来说,如果使用堵塞socket,通常我们通常开一个线程acceptsocket,当读完这次socket请求的时候,开一个单独的线程处理这个socket请求;如果使用非堵塞socket,通常是只有一个线程,一开始是select状,当有信号的时候可以通过多路复用(Multiplexing)技术传递给一个指定的线程池来处理请求,然后原来的线程继续select状态。 最简单的多路复用技术可以通过java管道(Pipe)来实现。 换句话说,如果客户端的并发请求很大的时候,客户系统可以使用少于客户端并发请求的线程数来处理这些请求,而这些来不及立即处理的请求会被阻塞在java管道或者队列里面,等待线程池的处理。 在web服务器上阻塞IO(BIO)与NIO一个比较重要的不同是,客户系统使用BIO的时候往往会为每一个web请求引入多线程,每个web请求一个单独的线程,所以并发量一旦上去了,线程数就上去了,CPU就忙着线程切换,所以BIO不合适高吞吐量、高可伸缩的web服务器;而NIO则是使用单线程(单个CPU)或者只使用少量的多线程(多CPU)来接受Socket,而由线程池来处理堵塞在pipe或者队列里的请求.这样的话,只要OS可以接受TCP的连接,web服务器就可以处理该请求。 大大提高了web服务器的可伸缩性。 客户只需要在server.xml里把HTTPConnector做如下更改: [html]viewplaincopy 改为 [html]viewplaincopy 然后启动服务器,如果出现org.apache.coyote.http11.Http11NioProtocolstart的提示信息,表示NIO已经启动。 其他的配置请参考官方配置文档。 2.2.5 其它 前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击,同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。 Tomcat提供了两个参数供你配置: RemoteHostValve和RemoteAddrValve。 通过配置这两个参数,可以让你过滤来自请求的主机或IP地址,并允许或拒绝哪些主机/IP。 与之类似的,在Apache的httpd文件里有对每个目录的允许/拒绝指定。 例如你可以把AdminWebapplication设置成只允许本地访问,设置如下: [html]viewplaincopy
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何 优化 提高 tomcat 启动 速度
![提示](https://static.bdocx.com/images/bang_tan.gif)