❶ linux下安装tomcat的默认安装目录在哪
Ubuntu的tomcat安装包，解压后，就是安装目录从官网http://tomcat.apache.org/下载tomcat，保存并拿在/home目录下。# cp apache-tomcat-6.0.20.tar.gz /home# cd /home#tar -zxvf apache-tomcat-6.0.20.tar.gz# lsapache-tomcat-6.0.18 jdk-6u30-linux-i586.bin mytask.sh web.warjdk1.6.0_30 ljq ubuntu# cd apache-tomcat-6.0.18/# lsbin lib logs RELEASE-NOTES temp workconf LICENSE NOTICE RUNNING.txt webappstomcat目录解析：bin：存放启动和关闭Tomcat的可执行脚本。conf：Tomcat的配置文件，如server.xml(Tomcat服务器配置文件)和或蔽中web.xml(被所有webapps共享的配置文件)，密码忘了看 tomcat-users.xml。webapps：存放web applications，用户自己需要部署的应用程序也放到此目录。work：tomcat运行时生成的临时文件，包括jsp编译后产生的class文件等。logs：存放日志文件。temp：JVM用于存放临时文件的目录(java.io.tmpdir)。/home/apache-tomcat-6.0.18/bin# ./startup.sh //启动tomcat/home/apache-tomcat-6.0.18/bin# ./shutdown.sh //关闭tomcat/home/apache-tomcat-6.0.18/logs# tail -f catalina.out //查看tomcat日志(-f表示会不衫山断打印新的日志出来)
❷ Tomcat配置实践
要部署使用tomcat，则必须了解tomcat的目录结构以及各目录的作用。这里以tomcat7为例，进入tomcat安装目录下：
前端请求被tomcat直接接收或者由前端的代理，通过HTTP，或者AJP代理给Tomcat，此时请求被tomcat中的connector接收，不同的connector和Engine被service组件关联起来，在一个Engine中定义了许多的虚拟主机，由Host容器定义，每一个Host容器代表一个主机，在各自的Host中，又可以定义多个Context，用此来定义一个虚拟主机中的多个独立的应用程序。
Tomcat Server的结构图如下：
看上去很复杂。其实，大部分都是注释。下面是一个简图说明了各组件之间的关系！
上面列出的比较常用的组件元素，server.xml文件中可定义的元素非常多，包括Server, Service, Connector, Engine, Cluster, Host, Alias, Context, Realm, Valve, Manager, Listener, Resources, Resource, ResourceEnvRef, ResourceLink, WatchedResource, GlobalNameingResources, Store, Transaction, Channel, Membership, Transport, Member, ClusterListener等等。
由以上配置不难看出存在的一个问题。如果我们想要对其中一个应用程序的配置做一些修改，那么就必须重新启动tomcat，那样势必就会影响到另外两个应用程序的正常服务。因此以上配置是不适合线上使用的， 因此需要将其配置为多实例，每个实例只跑一个独立的应用程序，那样我们应用程序之间就不会在互相受到影响。 但是我们将面临这样一竖雹个问题，80端口只能被一个HTTP/1.1 Connector监听，而三个tomcat实例则至少需要3个HTTP/1.1 Connector，这样我们就 需要一个前端代理做分发处理，接收HTTP 80端口的请求，按域名通过每个tomcat实例的AJP/1.3 Connector传递请求 。而前端的代理选择apache，基于这样的思路，我们还可以做到tomcat的负载均衡，而且 apache会将接收的HTTP超文本传输报文重新封装成二进制格式通过AJP/1.3 协议传递给后端的tomcat处理 ，在效率上余指帆也是有明显的提升。
这会让Tomcat启动一个server实例（即一个JVM），它监听在8005端口以接收shutdown命令。各Server的定义不能使用同一个端口，这意味着如果在同一个物理机上启动了多个Server实例，必须配置它们使用不同的端口。这个端口的定义用于为管理员提供一个关闭此实例的便捷途径，因此，管理员可以直接telnet至此端口使用SHUTDOWN命令关闭此实例。不过，基于安全角度的考虑，这通常不允许远程进行。
该元素代表整个容器，是Tomcat实例的顶层元素。由org.apache.catalina.Server接口来定义。它包含一个或多个<Service>元素。并且它不能做为任何元素的子元素。
Service主要用于关联一个引擎和与此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收入站请求交将其转发至关联的引擎进行处理。因此，Service要包含一个引擎、一个或多个连接器。
该元素由org.apache.catalina.Service接口定义，它包含一个<Engine>元素，以及一个或多个<Connector>，这些Connector元素共享用同一个Engine元素。
Engine是Servlet处理器的一个实逗备例，即servlet引擎，默认为定义在server.xml中的Catalina。
每个Service元素只能有一个Engine元素。元素处理在同一个<Service>中所有<Connector>元素接收到的客户请求。由org.apahce.catalina.Engine接口定义。
位于Engine容器中用于接收请求并进行相应处理的主机或虚拟主机。
它由Host接口定义。一个Engine元素可以包含多个<Host>元素。每个<Host>的元素定义了一个虚拟主机。它包含了一个或多个Web应用<Context>。
Context在某些意义上类似于apache中的路径别名，一个Context定义用于标识tomcat实例中的一个Web应用程序。
它由Context接口定义。是使用最频繁的元素。每个<Context>元素代表了运行在虚拟主机上的单个Web应用。一个<Host>可以包含多个<Context>元素。每个web应用有唯一的一个相对应的Context代表web应用自身。servlet容器为第一个web应用创建一个 ServletContext对象。
由Connector接口定义。<Connector>元素代表与客户程序实际交互的组件，它负责接收客户请求，以及向客户返回响应结果。
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：
Tomcat应该考虑工作情形并为相应情形下的请求分别定义好需要的连接器才能正确接收来自于客户端的请求。一个引擎可以有一个或多个连接器，以适应多种请求方式。
定义连接器可以使用多种属性，有些属性也只适用于某特定的连接器类型。一般说来，常见于server.xml中的连接器类型通常有4种：
Connector元素共用属性：
HttpConnector元素的属性：
AJP Connector的属性：
即一个service配置多个端口，项目可以通过多个端口访问。 修改tomcat-homeconf下的server.xml，在Service下配置多个<Connector>即可。
在这个应用里，可以用8080端口号访问服务，也可以用8099端口号来访问服务; 服务放置的路径由host决定，上例中服务放在webapps下。
即配置多个service，每个service可以配置多个端口。修改tomcat-homeconf下的server.xml，添加多个Service即可。
注意：Service name、Engine name、appBase，端口号别忘了修改，以免重复。
以上三个service，发布的路径不同，项目分别发布在webapps、webapps1、webapps2下，访问不同的项目的方法：
在$CATALINA_HOME/conf/server.xml配置文件中的Connetctor节点，和连接数相关的参数配置和优化。
Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值200。 可以根据机器的时期性能和内存大小调整，一般可以在400-500 。最大可以在800左右。
指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。
Tomcat初始化时创建的线程数。默认值4。
一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值50。
是否反查域名，默认值为true。 为了提高处理能力，应设置为false 。
网络连接超时，默认值20000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。 通常可设置为30000毫秒 。
保持请求数量，默认值100。
输入流缓冲大小，默认值2048 bytes。
压缩传输，取值on/off/force，默认值off。
其中和最大连接数相关的参数为maxThreads和acceptCount。 如果要加大并发连接数，应同时加大这两个参数 。 web server允许的最大连接数还受制于操作系统的内核参数设置 ，通常Windows是2000个左右，Linux是1000个左右。
配置示例：
Tomcat默认可以使用的内存为128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件$CATALINA_HOME/bin/catalina.sh的前面，增加如下设置：
一般说来，你应该使用物理内存的 80% 作为堆大小。如果本机上有Apache服务器，可以先折算Apache需要的内存，然后修改堆大小。 建议设置为70％；建议设置[初始化内存大小]等于[可以使用的最大内存]，这样可以减少频繁分配堆而降低性能。
在$CATALINA_HOME/conf/web.xml中，把listings参数设置成false即可，如下：
参考
WEB请求处理四：Tomcat配置实践
❸ tomcat 7的默认t配置文件在哪里
tomcat通常分为安装版和压缩版.看你是什么方式进行的安装.不正含过无穗祥论那种方式,你都可以使用文件名查找方式进行.windows:略linux:find / -name "tomcat"查找举族笑到后,通常在文件夹下的conf文件夹中.
❹ 详解 Tomcat 配置文件 server.xml
前言Tomcat隶属于Apache基金会，是开源的轻量级Web应用服务器，使用非常广泛。server.xml是Tomcat中最重要的配置文件，server.xml的每一个元素都对应了Tomcat中的一个组件；通过对xml文件中元素的配置，可以实现对Tomcat中各个组件的控制。因此，学习server.xml文件的配置，对于了解和使用Tomcat至关重要。 本文将通过实例，介绍server.xml中各个组件的配置，并详细说明Tomcat各个核心组件的作用以及各个组件之间的相互关系。 说明：由于server.xml文件中元素与Tomcat中组件的对应关系，后文中为了描述方便，“元素”和“组件”的使用不严格区分。 一、一个server.xml配置实例 server.xml位于$TOMCAT_HOME/conf目录下；下面是一个server.xml实例。后文中将结合该实例讲解server.xml中，各个元素的含义和作用；在阅读后续章节过程中，可以对照该xml文档便于理解。 二、server.xml文档的元素分类和整体结构 1、整体结构 server.xml的整体结构如下： 该结构中只给出了Tomcat的核心组件，除了核心组件外，Tomcat还有一些其他组件，下面介绍一下组件的分类。 2、元素分类 server.xml文件中的元素可以分为以下4类： （1）顶层元素：和 元素是整个配置文件的根元素，元素则代表一个Engine元素以及一组与之相连的Connector元素。 （2）连接器： 代表了外部客户端发送请求到特定Service的接口；同时也是外部客户端从特定Service接收响应的接口。 （3）容器： 容器的功能是处理Connector接收进来的请求，并产生相应的响应。Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。一个Engine组件可以处理Service中的所有请求，一个Host组件可以处理发向一个特定虚拟主机的所有请求，一个Context组件可以处理一个特定Web应用的所有请求。 （4）内嵌组件：可以内嵌到容器中的组件。实际上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat组件，其他组件都可以归为内嵌组件。 下面将详细介绍Tomcat中各个核心组件的作用，以及相互之间的关系。 三、核心组件 本部分将分别介绍各个核心组件的作用、特点以及配置方式等。 1、Server Server元素在最顶层，代表整个Tomcat容器，因此它必须是server.xml中唯一一个最外层的元素。一个Server元素中可以有一个或多个Service元素。 在第一部分的例子中，在最外层有一个元素，shutdown属性表示关闭Server的指令；port属性表示Server接收shutdown指令的端口号，设为-1可以禁掉该端口。 Server的主要任务，就是提供一个接口让客户端能够访问到这个Service集合，同时维护它所包含的所有的Service的声明周期，包括如何初始化、如何结束服务、如何找到客户端要访问的Service。 2、Service Service的作用，是在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service可以包含多个Connector，但是只能包含一个Engine；其中Connector的作用是从客户端接收请求，Engine的作用是处理接收进来的请求。 在第一部分的例子中，Server中包含一个名称为“Catalina”的Service。实际上，Tomcat可以提供多个Service，不同的Service监听不同的端口，后文会有介绍。 3、Connector Connector的主要功能，是接收连接请求，创建Request和Response对象用于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产生的Request和Response对象传给Engine。 通过配置Connector，可以控制请求Service的协议及端口号。在第一部分的例子中，Service包含两个Connector： 在这个例子中，Tomcat监听HTTP请求，使用的是8080端口，而不是正式的80端口；实际上，在正式的生产环境中，Tomcat也常常监听8080端口，而不是80端口。这是因为在生产环境中，很少将Tomcat直接对外开放接收请求，而是在Tomcat和客户端之间加一层代理服务器(如nginx)，用于请求的转发、负载均衡、处理静态文件等；通过代理服务器访问Tomcat时，是在局域网中，因此一般仍使用8080端口。 （2）通过配置第2个Connector，客户端可以通过8009端口号使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要用到这个连接器。之所以使用Tomcat和其他服务器集成，是因为Tomcat可以用作Servlet/JSP容器，但是对静态资源的处理速度较慢，不如Apache和IIS等HTTP服务器；因此常常将Tomcat与Apache等集成，前者作Servlet容器，后者处理静态资源，而AJP协议便负责Tomcat和Apache的连接。Tomcat与Apache等集成的原理如下图(图片来源)：4、Engine Engine组件在Service组件中有且只有一个；Engine是Service组件中的请求处理组件。Engine组件从一个或多个Connector中接收请求并处理，并将完成的响应返回给Connector，最终传递给客户端。 前面已经提到过，Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。 在第一部分的例子中，Engine的配置语句如下： 其中，name属性用于日志和错误信息，在整个Server中应该唯一。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。 5、Host （1）Engine与Host Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。 （2）Host的作用 Host虚拟主机的作用，是运行多个Web应用（一个Context代表一个Web应用），并负责安装、展开、启动和结束每个Web应用。 Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如”www.test.com”，或IP地址”116.25.25.25”)；为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。 客户端通常使用主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻找名称匹配的主机。如果没有匹配，请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名，因为任何与所有Host名称不匹配的请求，都会路由至默认主机。 （3）Host的配置 在第一部分的例子中，Host的配置如下： 下面对其中配置的属性进行说明： name属性指定虚拟主机的主机名，一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；一般情况下，主机名需要是在DNS服务器中注册的网络名，但是Engine指定的defaultHost不需要，原因在前面已经说明。 unpackWARs指定了是否将代表Web应用的WAR文件解压；如果为true，通过解压后的文件结构运行该Web应用，如果为false，直接使用WAR文件运行Web应用。 Host的autoDeploy和appBase属性，与Host内Web应用的自动部署有关；此外，本例中没有出现的xmlBase和deployOnStartup属性，也与Web应用的自动部署有关；将在下一节(Context)中介绍。 6、Context （1）Context的作用 Context元素代表在特定虚拟主机上运行的一个Web应用。在后文中，提到Context、应用或Web应用，它们指代的都是Web应用。每个Web应用基于WAR文件，或WAR文件解压后对应的目录（这里称为应用目录）。 Context是Host的子容器，每个Host中可以定义任意多的Context元素。 在第一部分的例子中，可以看到server.xml配置文件中并没有出现Context元素的配置。这是因为，Tomcat开启了自动部署，Web应用没有在server.xml中配置静态部署，而是由Tomcat通过特定的规则自动部署。下面介绍一下Tomcat自动部署Web应用的机制。 （2）Web应用自动部署 Host的配置 要开启Web应用的自动部署，需要配置所在的虚拟主机；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果deployOnStartup和autoDeploy设置为true，则tomcat启动自动部署：当检测到新的Web应用或Web应用的更新时，会触发应用的部署(或重新部署)。二者的主要区别在于，deployOnStartup为true时，Tomcat在启动时检查Web应用，且检测到的所有Web应用视作新应用；autoDeploy为true时，Tomcat在运行时定期检查新的Web应用或Web应用的更新。除此之外，二者的处理相似。 通过配置deployOnStartup和autoDeploy可以开启虚拟主机自动部署Web应用；实际上，自动部署依赖于检查是否有新的或更改过的Web应用，而Host元素的appBase和xmlBase设置了检查Web应用更新的目录。 其中，appBase属性指定Web应用所在的目录，默认值是webapps，这是一个相对路径，代表Tomcat根目录下webapps文件夹。 xmlBase属性指定Web应用的XML配置文件所在的目录，默认值为conf//，例如第一部分的例子中，主机localhost的xmlBase的默认值是$TOMCAT_HOME/conf/Catalina/localhost。 检查Web应用更新 一个Web应用可能包括以下文件：XML配置文件，WAR包，以及一个应用目录(该目录包含Web应用的文件结构)；其中XML配置文件位于xmlBase指定的目录，WAR包和应用目录位于appBase指定的目录。 Tomcat按照如下的顺序进行扫描，来检查应用更新： A、扫描虚拟主机指定的xmlBase下的XML配置文件 B、扫描虚拟主机指定的appBase下的WAR文件 C、扫描虚拟主机指定的appBase下的应用目录 元素的配置 Context元素最重要的属性是docBase和path，此外reloadable属性也比较常用。 docBase指定了该Web应用使用的WAR包路径，或应用目录。需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定；如果docBase指定的WAR包或应用目录就在docBase中，则不需要指定，因为Tomcat会自动扫描appBase中的WAR包和应用目录，指定了反而会造成问题。 path指定了访问该Web应用的上下文路径，当请求到来时，Tomcat根据Web应用的 path属性与URI的匹配程度来选择Web应用处理相应请求。例如，Web应用app1的path属性是”/app1”，Web应用app2的path属性是”/app2”，那么请求/app1/index.html会交由app1来处理；而请求/app2/index.html会交由app2来处理。如果一个Context元素的path属性为””，那么这个Context是虚拟主机的默认Web应用；当请求的uri与所有的path都不匹配时，使用该默认Web应用来处理。 但是，需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，不能指定path属性，path属性由配置文件的文件名、WAR文件的文件名或应用目录的名称自动推导出来。如扫描Web应用时，发现了xmlBase目录下的app1.xml，或appBase目录下的app1.WAR或app1应用目录，则该Web应用的path属性是”app1”。如果名称不是app1而是ROOT，则该Web应用是虚拟主机默认的Web应用，此时path属性推导为””。 reloadable属性指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。如果值为true，那么当class文件改动时，会触发Web应用的重新加载。在开发环境下，reloadable设置为true便于调试；但是在生产环境中设置为true会给服务器带来性能压力，因此reloadable参数的默认值为false。 下面来看自动部署时，xmlBase下的XML配置文件app1.xml的例子：在该例子中，docBase位于Host的appBase目录之外；path属性没有指定，而是根据app1.xml自动推导为”app1”；由于是在开发环境下，因此reloadable设置为true，便于开发调试。 自动部署举例 最典型的自动部署，就是当我们安装完Tomcat后，$TOMCAT_HOME/webapps目录下有如下文件夹：当我们启动Tomcat后，可以使用http://localhost:8080/来访问Tomcat，其实访问的就是ROOT对应的Web应用；我们也可以通过http://localhost:8080/docs来访问docs应用，同理我们可以访问examples/host-manager/manager这几个Web应用。 （3）server.xml中静态部署Web应用 除了自动部署，我们也可以在server.xml中通过元素静态部署Web应用。静态部署与自动部署是可以共存的。在实际应用中，并不推荐使用静态部署，因为server.xml 是不可动态重加载的资源，服务器一旦启动了以后，要修改这个文件，就得重启服务器才能重新加载。而自动部署可以在Tomcat运行时通过定期的扫描来实现，不需要重启服务器。 server.xml中使用Context元素配置Web应用，Context元素应该位于Host元素中。举例如下： 1 docBase：静态部署时，docBase可以在appBase目录下，也可以不在；本例中，docBase不在appBase目录下。 path：静态部署时，可以显式指定path属性，但是仍然受到了严格的限制：只有当自动部署完全关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时，才可以设置path属性。在本例中，docBase不在appBase中，因此path属性可以设置。 reloadable属性的用法与自动部署时相同。 四、核心组件的关联 1、整体关系 核心组件之间的整体关系，在上一部分有所介绍，这里总结一下： Server元素在最顶层，代表整个Tomcat容器；一个Server元素中可以有一个或多个Service元素。 Service在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service可以包含多个Connector，但是只能包含一个Engine；Connector接收请求，Engine处理请求。 Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每个Host组件代表Engine中的一个虚拟主机；每个Context组件代表在特定Host上运行的一个Web应用。 2、如何确定请求由谁处理？ 当请求被发送到Tomcat所在的主机时，如何确定最终哪个Web应用来处理该请求呢？ （1）根据协议和端口号选定Service和Engine Service中的Connector组件可以接收特定端口的请求，因此，当Tomcat启动时，Service组件就会监听特定的端口。在第一部分的例子中，Catalina这个Service监听了8080端口（基于HTTP协议）和8009端口（基于AJP协议）。当请求进来时，Tomcat便可以根据协议和端口号选定处理请求的Service；Service一旦选定，Engine也就确定。 通过在Server中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。 （2）根据域名或IP地址选定Host Service确定后，Tomcat在Service中寻找名称与域名/IP地址匹配的Host处理该请求。如果没有找到，则使用Engine中指定的defaultHost来处理该请求。在第一部分的例子中，由于只有一个Host（name属性为localhost），因此该Service/Engine的所有请求都交给该Host处理。 （3）根据URI选定Context/Web应用 这一点在Context一节有详细的说明：Tomcat根据应用的 path属性与URI的匹配程度来选择Web应用处理相应请求，这里不再赘述。 （4）举例 以请求http://localhost:8080/app1/index.html为例，首先通过协议和端口号（http和8080）选定Service；然后通过主机名（localhost）选定Host；然后通过uri（/app1/index.html）选定Web应用。 3、如何配置多个服务 通过在Server中配置多个Service服务，可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。 在server.xml中配置多服务的方法非常简单，分为以下几步： （1）复制元素，放在当前后面。 （2）修改端口号：根据需要监听的端口号修改元素的port属性；必须确保该端口没有被其他进程占用，否则Tomcat启动时会报错，而无法通过该端口访问Web应用。 以Win7为例，可以用如下方法找出某个端口是否被其他进程占用：netstat -aon|findstr “8081″发现8081端口被PID为2064的进程占用，tasklist |findstr “2064″发现该进程为FrameworkService.exe(这是McAfee杀毒软件的进程)。（3）修改Service和Engine的name属性 （4）修改Host的appBase属性（如webapps2） （5）Web应用仍然使用自动部署 （6）将要部署的Web应用(WAR包或应用目录)拷贝到新的appBase下。 以第一部分的server.xml为例，多个Service的配置如下： http://localhost:8080/docs/ http://localhost:8084/docs/ 五、其他组件 除核心组件外，server.xml中还可以配置很多其他组件。下面只介绍第一部分例子中出现的组件，如果要了解更多内容，可以查看Tomcat官方文档。 1、Listener Listener(即监听器)定义的组件，可以在特定事件发生时执行特定的操作；被监听的事件通常是Tomcat的启动和停止。 监听器可以在Server、Engine、Host或Context中，本例中的监听器都是在Server中。实际上，本例中定义的6个监听器，都只能存在于Server组件中。监听器不允许内嵌其他组件。 监听器需要配置的最重要的属性是className，该属性规定了监听器的具体实现类，该类必须实现了org.apache.catalina.LifecycleListener接口。 下面依次介绍例子中配置的监听器： VersionLoggerListener：当Tomcat启动时，该监听器记录Tomcat、Java和操作系统的信息。该监听器必须是配置的第一个监听器。 AprLifecycleListener：Tomcat启动时，检查APR库，如果存在则加载。APR，即Apache Portable Runtime，是Apache可移植运行库，可以实现高可扩展性、高性能，以及与本地服务器技术更好的集成。 JasperListener：在Web应用启动之前初始化Jasper，Jasper是JSP引擎，把JVM不认识的JSP文件解析成java文件，然后编译成class文件供JVM使用。 ：与类加载器导致的内存泄露有关。 ：通过该监听器，初始化< GlobalNamingResources>标签中定义的全局JNDI资源；如果没有该监听器，任何全局资源都不能使用。< GlobalNamingResources>将在后文介绍。 ：当Web应用因thread-local导致的内存泄露而要停止时，该监听器会触发线程池中线程的更新。当线程执行完任务被收回线程池时，活跃线程会一个一个的更新。只有当Web应用(即Context元素)的属性设置为true时，该监听器才有效。 2、GlobalNamingResources与Realm 第一部分的例子中，Engine组件下定义了Realm组件： Realm，可以把它理解成“域”；Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用。在本例中，Realm的配置使用name为UserDatabase的资源实现。而该资源在Server元素中使用GlobalNamingResources配置： GlobalNamingResources元素定义了全局资源，通过配置可以看出，该配置是通过读取$TOMCAT_HOME/ conf/tomcat-users.xml实现的。 关于Tomcat域管理的更多内容，可以参考：Realm域管理 3、Valve 在第一部分的例子中，Host元素内定义了Valve组件： 单词Valve的意思是“阀门”，在Tomcat中代表了请求处理流水线上的一个组件；Valve可以与Tomcat的容器(Engine、Host或Context)关联。 不同的Valve有不同的特性，下面介绍一下本例中出现的AccessLogValve。 AccessLogValve的作用是通过日志记录其所在的容器中处理的所有请求，在本例中，Valve放在Host下，便可以记录该Host处理的所有请求。AccessLogValve记录的日志就是访问日志，每天的请求会写到一个日志文件里。AccessLogValve可以与Engine、Host或Context关联；在本例中，只有一个Engine，Engine下只有一个Host，Host下只有一个Context，因此AccessLogValve放在三个容器下的作用其实是类似的。 本例的AccessLogValve属性的配置，使用的是默认的配置；下面介绍AccessLogValve中各个属性的作用： （1）className：规定了Valve的类型，是最重要的属性；本例中，通过该属性规定了这是一个AccessLogValve。 （2）directory：指定日志存储的位置，本例中，日志存储在$TOMCAT_HOME/logs目录下。 （3）prefix：指定了日志文件的前缀。 （4）suffix：指定了日志文件的后缀。通过directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目录下，可以看到如下所示的日志文件。（5）pattern：指定记录日志的格式，本例中各项的含义如下： %h：远程主机名或IP地址；如果有nginx等反向代理服务器进行请求分发，该主机名/IP地址代表的是nginx，否则代表的是客户端。后面远程的含义与之类似，不再解释。 %l：远程逻辑用户名，一律是”-”，可以忽略。 %u：授权的远程用户名，如果没有，则是”-”。 %t：访问的时间。 %r：请求的第一行，即请求方法(get/post等)、uri、及协议。 %s：响应状态，200,404等等。 %b：响应的数据量，不包括请求头，如果为0，则是””-。 例如，下面是访问日志中的一条记录pattern的配置中，除了上述各项，还有一个非常常用的选项是%D，含义是请求处理的时间(单位是毫秒)，对于统计分析请求的处理速度帮助很大。 开发人员可以充分利用访问日志，来分析问题、优化应用。例如，分析访问日志中各个接口被访问的比例，不仅可以为需求和运营人员提供数据支持，还可以使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，可以知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，可以找出慢请求，并根据需要进行响应时间的优化。
❺ embedtomcat默认配置
embedtomcat默认配置步骤如下。1、把自己开发的项目下的webroot复制到ROOT下(先念首删除掉原有的的ROOT下东西)，重启，应该就OK了。2、找仔早数到TOMCAT_HOME/conf/server、xml，编辑标签，在其中添加，其中jpetstore为你要直接访问的项目名称。3、最睁胡后的结果就是：，重启，应该就OK了。
❻ TOMCAT配置文件 目录描述
1、TOMCAT配置文件：$CATALINA_HOME/conf/web.xml配置简介<servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>说明：<servlet-name>：定义Servlet的名字。<servlet-class>：指定实现这个Servlet的类。<init-param>：定义Servlet的初始化参数（包括参数名和参数值），一个 <servlet>元素中可以有多个<init-param>元素。<load-on-startup>：指定当Web应用启动时，装载Servlet的次序。当这个值为正数或零，Servlet容器先加载数值小的Servlet，再一次加载其他数值大的Servlet。如果这个值为负数或没有设定，Servlet将在Web客户首次访问这个Servlet时加载它。<session-config> <session-timeout>30</session-timeout> </session-config>a.如果某文件资源没有找到，服务器要报404错误，按下述配置则会调用\webapps\ROOT\notFileFound.jsp<error-page> <error-code>404</error-code> <location>/notFileFound.jsp</location></error-page>b.如果执行的某个JSP文件产生NullPointException，则会调用\webapps\ROOT\null.jsp<error-page> <exception-type>java.lang.NullPointerException</exception-type> <location>/null.jsp</location></error-page><welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file></welcome-file-list>默认Web应用的首页文件的设置报错文件的设置session 会话过期时间的设置,单位是分钟servlet的设置filter过滤器的设置<filter> <filter-name>FilterSource</filter-name> <filter-class>project4. FilterSource </filter-class></filter><filter-mapping> <filter-name>FilterSource</filter-name> <url-pattern>/WwwServlet</url-pattern> (<url-pattern>/haha/*</url-pattern>)</filter-mapping>2、TOMCAT的目录结构/bin：存放windows或Linux平台上启动和关闭Tomcat的脚本文件/conf：存放Tomcat服务器的各种全局配置文件，其中最重要的是server.xml和web.xml/doc：存放Tomcat文档/server：包含三个子目录：classes、lib和webapps/server/lib：存放Tomcat服务器所需的各种JAR文件/server/webapps：存放Tomcat自带的两个WEB应用admin应用和 manager应用/common/lib：存放Tomcat服务器以及所有web应用都可以访问的jar文件/shared/lib：存放所有web应用都可以访问的jar文件（但是不能被Tomcat服务器访问）/logs：存放Tomcat执行时的日志文件/src：存放Tomcat的源代码/webapps：Tomcat的主要Web发布目录，默认情况下把Web应用文件放于此目录/work：存放JSP编译后产生的class文件
❼ tomcat 的配置文件有那些
tomcat的配置文件可能出现的问题如下：一、正确的配置方法：(1)jdk配置：新建java_home=d:programfilesjavajdk1.6.0编辑path：（java_home在用户变量path也要在用户变量中）path=%java_home%in;在系统变量中新建：classpath=.;%java_home%lib;%java_home%lib*.jar;classpath必须在系统变量中建（2）tomcat配置：catalina_home=d:apache-tomcat-6.0.18（或者是tomcat_home=d:apache-tomcat-6.0.18）二、tomcat启动后一闪而过：1.如果双击startup.bat,窗口一闪而过，可以在命令行里面启动startup.bat；2.如果命令行里面启动startup.bat情况还是这样，就可以在bat命令后面加上pause，这样就不会一闪而过了；三、其他一些关于tomcat启动时的奇怪问题：a.tomcat无法从"开始"中启动,但可以在startup.bat中启动jdk版本过低b.启动的时候，加载信息的提示界面在屏幕上停留几秒钟就消失了，同时，tomcat的应用程序也自动关闭在server.xml的最后，/host之上，应该写上的是：contentc.tomcat启动时有一些显示,但仍会自动关闭,无法启动.可能是地址被占用,运行桌面上的"关闭tomcat"快捷方式,执行完毕后再启动tomcat.d.tomcat启动时一闪而过,无法启动.可能是端口被占用,可找到tomcat的安装目录下的server.xml文件,如..eam2003confserver.xml,用记事本打开此文件,查找8080,如果找到,就将8080改为8088.
❽ Tomcat基础(2)
Tomcat服务器的配置主要集中于tomcat/conf下的catalina.policy, catalina.properties,context.xml、server.xml、tomcat-users.xml、web.xml文件。 server.xml 是tomcat服务器的核心配置文件,包含了Tomcat的servlet容器(catalina)的所有配置。由于配置的属性特别多,我们在这里主要讲解其中的一部分重要配置。 Server是server.xml的根元素,用于创建一个Server实例,默认使用的实现类是org.apache.catalina.core.standardserver. port:Tomcat监听的关闭服务器的端口。 shutdown:关闭服务器的指令字符串。 Server内嵌的子元素为Listener, GlobalNamingResources, Service. 默认配置的5个Listener的含义 GlobalNamingResources中定义了全局命名服务 该元素用于创建Service实例,默认使用org.apache.catalina.core.Standardservice,默认情况下,Tomcat仅指定了Service的名称,值为"Catalina",Service可以内嵌的元素为:Listener, Executor, connector, Engine ,其中Listener用于为Service添加生命周期监听器,Executor用于配置Service共享线程池,Connector用于配置Service包含的链接器,Engine用于配置Service中链接器对应的Servlet容器引擎。一个Server服务器,可以包含多个Service服务。 默认情况下Service并未添加共享线程池配置，如果我们想添加一个线程池，可以在下添加如下配置： 属性说明 属性含义name线程池名称，用于Connector中指定。 nameprefix所创建的每个线程的名称前缀,一个单独的线程名称为namePrefix+threadNumber. maxThreads池中最大线程数。 minSpareThreads活跃线程数,也就是核心池线程数,这些线程不会被销毁,会一直存在。 maxIdleTime线程空闲时间,超过该时间后,空闲线程会被销毁,默认值为6000 (1分钟) ,单位毫秒。 maxQueuesize在被执行前最大线程排队数目,默认为Int的最大值,也就是广义的无限。除非特殊情况,这个值不需要更改,否则会有请求不会被处理的情况发生。 prestartminSpareThreads启动线程池时是否启动minSpareThreads部分线程。默认值为false,即不启动。 threadPriority线程池中线程优先级,默认值为5,值从1到10。 className 线程池实现类,未指定情况下，默认实现类为org.apache.catalina.core.standardThreadExecutor,如果想使用自定义线程池首先需要实现 org.apache.catalina.Executor接口。 JDK工具jconsole.exe观察线程池被创建 如果不配置共享线程池，那么Catalina各组件在用到线程池时会独立创建。 Connector用于创建链接器实例。默认情况下, server.xml配置了两个链接器,一个支持HTTP协议,一个支持AJP协议。因此大多数情况下,我们并不需要新增链接器配置,只是根据需要对已有链接器进行优化。 属性说明 1) port:端口号,Connector用于创建服务端Socket并进行监听,以等待客户端请求链接。如果该属性设置为0,Tomcat将会随机选择一个可用的端口号给当前Connector使用。 2)protocol :当前Connector支持的访问协议。默认为HTTP/1.1 ,并采用自动切换机制选择一个基于JAVA NIO的链接器或者基于本地APR的链接器(根据本地是否含有Tomcat的本地库判定)。 如果不希望采用上述自动切换的机制,而是明确指定协议,可以使用以下值。 Http协议: AJP协议 3) connectionTimeOut: Connector接收链接后的等待超时时间,单位为毫秒。-1表示不超时。 4)redirectPort:当前Connector不支持SSL(HTTP协议证书)请求,接收到了一个请求,并且也符合security-constraint约束,需要SSL传输,Catalina自动将请求重定向到指定的端口。 5)executor:指定共享线程池的名称, 也可以通过maxThreads, minSpareThreads等属性配置内部线程池。 6)URIEncoding:用于指定编码URI的字符编码, Tomcat8.x版本默认的编码为UTF-8，Tomcat7.X版本默认为ISO-8859-1(解决请求字符串乱码问题，Tomcat8版本默认UTF-8不需要指定URI字符编码)。 完整的配置如下: Engine作为Servlet引擎的顶级元素，内部可嵌入：Cluster、Listener、Realm、Valve和Host。 属性说明： 1)name：用于指定Engine的名称，默认为Catalina。该名称会影响一部分Tomcat的存储路径(如临时文件); 2)defaultHost：默认使用虚拟主机名称，当客户端请求指向的的主机无效时将交由默认虚拟主机处理，默认为localhost。 Host元素用于配置一个虚拟主机,它支持以下嵌入元素:Alias,cluster,Listener,valve,Realm,context,如果在Engine下配置Realm,那么此配置将在当前Engine下的所有Host中共享。同样,如果在Host中配置Realm , 则在当前Host下的所有context中共享。Context中的Realm优先级>Host的Realm优先级>Engine中的Realm优先级。 属性说明: 1)name:当前Host通用的网络名称,必须与DNS服务器上的注册信息一致。Engine中包含的Host必须存在一个名称与Engine的defaultHost设置一致。 2)appBase:当前Host的应用基础目录,当前Host上部署的web应用均在该目录下(可以是绝对目录,相对路径)。默认为webapps。 3)unpackWARs:设置为true, Host在启动时会将appBase目录下war包解压为目录。设置为false,Host将直接从war文件启动。 4)autoDeploy:控制tomcat是否在运行时定期检测并自动部署新增或变更的web应用。 通过给Host添加别名，我们可以实现同一个Host拥有多个网络名称，配置如下： Context用于配置一个web应用，默认配置如下： 属性描述 ： 1)docBase：Web应用目录或War包的部署路径。可以是绝对路径，也可以是相对于Host appBase的相对路径。 2)Path：Web应用的Context路径。如果我们Host名为localhost，则该web应用访问的路径为： http://localhost:8080/myApp 它支持的内嵌元素为:CookieProcessor,Loader,Manager,Realm,Resources,WatchedResource,Jarscanner,Valve. 该配置文件中，主要配置的是Tomcat的用户，角色等信息，用来控制Tomcat中manager，host-manager的访问权限。 web.xml是web应用的描述文件, 它支持的元素及属性来自于servlet规范定义。在Tomcat中,web应用的描述信息包括tomcat/conf/web.xml中默认配置以及web应用WEB-INE/web.xml下的定制配置。 我们可以通过<context-param>添加ServletContext初始化参数，它配置了一个键值对，这样我们可以在应用程序中使用javax.servlet.ServletContext.getInitParameter()方法获取参数。 可以直接在servlet中进行应用 。 5.2 会话配置 <session-config>用于配置web应用会话，包括超时时间Cookie配置以及 会话追踪模式 。它将覆盖server.xml和context.xml 1)session-timeout:超时时间,单位分钟。 2)cookie-config:用于配置会话追踪Cookie nane:Cookie的名称 domain:Cookie的域名 path: Cookie的路径 comment: 注释 http-only:cookie只能通过HTTP方式进行访问, JS无法读取或修改,此项可以增加网站访问的安全性。 secuze :设置true则此cookie只能通过HTTPS连接传递到服务器,而HTTP连接则不会传递该信息。注意是从浏览器传递到服务器,服务器端的Cookie对像不受此项影响。 max-age:以秒为单位表示cookie的生存期,默认为-1表示是会话Cookie ,浏览器关闭时就会消失。 3)tracking-mode:用于配置会话追踪模式,Servlet3.0版本中支持追踪模式:COOKIE,URL,SSL ACOOKIE:通过HTTP Cookie 追踪会话是最常用的会话追踪机制, 而且Servlet规范也要求所有的Servlet规范都需要支持Cookie追踪。 B.URL:URL重写是最基本的会话追踪机制。当客户端不支持Cookie时,可以采用URI重写的方式。当采用URI追踪模式时,请求路径需要包含会话标识信息,Servlet容器会根据路径中的会话标识设置请求的会话信息。如:"http: //www.myserver.com/user/index.html;jessionid=1234567890。 C.SSL:对于SSL请求,通过SSL会话标识确定请求会话标识。 Servlet的配置主要是两部分，servlet和servlet-mapping； 配置说明： 1)sexvlet-name:指定servle的名称,该属性在web.xml中唯一。 2)servlet-class:用于指定servlet类名 3)init-param:用于指定servlet的初始化参数, 在应用中可以通过HttpServlet.getInitParameter获取。 4) load-on-startup:用于控制在Web应用启动时,Servlet的加载顺序。值小于0, web应用启动时,不加载该servlet,第一次访问时加载 5)enabled: true ,false。若为false ,表示servlet不处理任何请求。 6)url-pattern:用于指定URL表达式,一个servlet-mapping可以同时配置多个url-pattern。 Servlet 中文件上传配置 配置说明： 1)location:存放生成的文件地址。 2) max-file-size:允许上传的文件最大值。默认值为-1,表示没有限制。 3)max-request-size:针对该multi/form-data请求的最大数量,默认值为-1,表示无限制。 4)file-size-threshold:当数量量大于该值时, 内容会被写入文件。 Listener用于监听servlet中的事件，例如context、request、session对象的创建、修改、删除，并触发响应响应。Listener是 观察者模式 的 实现 ，在servlet中主要用于context、request、session对象的生命周期进行监控。在servlet 2.5规范中共定义了8重Listener。在启动时，ServletContextListener的执行顺序与web.xml中的配置顺序一致，停止时执行顺序相反。 配置说明： 1)filter-name:用于指定过滤器名称,在web.xm1中,过滤器名称必须唯一。 2)filter-class:过滤器的全限定类名,该类必须实现Filter接口。 3)async-supported:该过滤器是否支持异步。 4)init-param:用于配置Filter的初始化参数,可以配置多个,可以通过 FilterConfig.getInitParameter 获取 5)url-pattern:指定该过滤器需要拦截的URL。 Tomcat conf/web.xml中配置了web默认访问页面。 Tomcat启动后会尝从上到下的请求顺序。 如果在项目的WEB-INF目录下的web.xml中配置访问页面，则会覆盖Tomcat中的默认配置。 error-page用于配置web项目访问异常时定向的页面，支持HTTP响应码和异常类两种形式。优化用户体验，保证系统安全。 Tomcat中自定义错误页面放入ROOT目录下。 项目中将错误页面放在web目录下，并且会覆盖Tomcat中的配置。 从早期的Tomcat版本开始,就提供了web版的管理控制台,他们是两个独立的web应用,位于webapps目录下。Tomcat提供的管理应用有用于管理的Host的host-manager和用于管理web应用的manager。 这两个web应用主要作用就是为Tomcat提供了管理后台，可以通过这两个应用去管理Tomcat中所配置的虚拟主机、Tomcat中部署的web应用、Tomcat占用的JVM内存分配、JVM参数配比等 Host-manager主要用来管理 虚拟主机 信息。Tomcat启动之后,可以通过 http://localhost:8080/host-manager/html 访问该web应用。host-manager默认添加了访问权限控制,当打开网址时,需要输入用户名和密码(conf/tomcat-users.xml中配置) 。所以要想访问该页面,需要在conf/tomcat-users.xml中配置,并分配对应的角色: 1)admin-gui:用于控制页面访问权限 2)admin-script:用于控制以简单文本的形式进行访问 配置如下: 界面： Manager用来管理部署在当前Tomcat上的web应用，访问路径为 http://localhost:8080/manager ，同样manager也添加了页面访问控制，因此我们需要为登录用户分配角色为： Server Status查看服务器状态，给JVM内存优化参考数据
❾ 1 如何优化Tomcat
（1）bin：主要用来存放命令，.bat是windows下，.sh是Linux下 （2）conf：主要用来存放tomcat的一些配置文件 （3）lib：存放tomcat依赖的一些jar包 （4）logs：存放tomcat在运行时产生的日志文件 （5）temp：存放运行时产生的临时文件 （6）webapps：存放应用程序 （7）work：存放tomcat运行时编译后的文件，比如JSP编译后的文件 tomcat优化可以有几个方向：配置项的删除，配置参数的修改，jdk参数修改、Tomcat内存优化、Tomcat并发优化、Tomcat缓存优化 web项目中自带的WEB-INF/web.xml， tomcat自带的conf/web.xml以及conf/server.xml文件。 因为这些xml文件都会被tomcat解析，所以优化方向是将这三类文件中不必要的配置删除。 tomcat在启动时，会将web项目中WEB-INF/web.xml和自己的conf/web.xml进行合并，然后在ContextConfig类下的configureContext()统一解析这些内容： 这个只能是在项目中不需要的配置不要放进去，有过期的配置要及时删除，减少tomcat的解析成本。 这是一个处理静态文件的servlet，如果项目中不需要tomcat进行静态文件的处理，可以将其删掉。 这个servlet是用来编译和执行jsp文件的，如果项目中没有jsp文件，可以将其删掉。 项目中没有jsp，关于jsp下面的映射也可以删除： 文件中提供的mime类型非常多，如果有确定项目中不会涉及到的类型，可以删除其映射配置。 如果不需要展示tomcat的欢迎页，可以将其删掉。 下面是tomcat8.5版本提供的默认listener列表： 作用是在Tomcat初始化时，打印一下Tomcat相关的版本信息以及操作系统和jdk环境信息，可以删掉。 Tomcat启动时，检查APR库，如果存在则加载，这个配置仅当connector的protocol设置为AJP/1.3时有用，如果非AJP/1.3，可以删除。 Java运行环境可能导致某些已知位置的内存泄漏或文件锁定， 提供这些情况的解决方案。 作用于全局资源，通过该监听器，初始化标签中定义的全局JNDI资源； 如果没有该监听器，定义的全局资源都不能使用。 如果不使用GlobalNamingResources定义全局资源，可以删除。 Web应用因thread-local导致的内存泄露而要停止时，该监听器会触发线程池中线程的更新。 只有当Web应用(即Context元素)的属性设置为true时，该监听器才有效。 官方文档对配置的解释为： GlobalNamingResources可以定义全局资源，可以看出，这个tomcat的默认配置是通过读取$TOMCAT_HOME/ conf/tomcat-users.xml实现的。 tomcat-user.xml用于定义tomcat管理页面相关配置，如果不登录管理界面可以删掉。 官网中对于这个connector有如下描述： The AJP Connector element represents a Connector component that communicates with a web connector via the AJP protocol. This is used for cases where you wish to invisibly integrate Tomcat into an existing (or new) Apache installation, and you want Apache to handle the static content contained in the web application, and/or utilize Apache's SSL processing. 可知当tomcat需要集成到Apache服务器时才使用这个connector，现在一般都用Nginx代替Apache，所以不使用Apache的话这个也可以删掉。 tomcat默认配置包含如下connector： <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> Realm，可以把它理解成“域”； Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用，tomcat默认的这个realm是和name为UserDatabase的资源绑定的，而该资源在Server元素中使用GlobalNamingResources配置。如果不需要可以删掉。 Valve的意思是“阀门”，不同的Valve有不同的特性，Valve的配置中AccessLogValve的作用是记录其所在容器处理的所有请求，默认配置中的Valve放在Host下，便可以记录该Host处理的所有请求。 AccessLogValve记录的日志就是访问日志，每天的请求会写到一个日志文件里。现在一般记录Nginx访问日志，这个也可以删除。 tomcat是用Java写的，就要运行在jvm上，垃圾处理方式等都要遵循jvm的方式。 tomcat中设置jvm参数在 catalina.sh(Linux)和catalina.bat(windows)中，以JAVA_OPTS变量存储。以catalina.sh为例： 可以在该变量中添加jvm参数，达到减少gc次数等目标，例如根据tomcat所在服务器修改jvm内存大小等。 参数优化主要是优化sever.xml中的配置参数，示例server.xml如下： port：指定一个端口，这个端口负责监听关闭tomcat的请求。 shutdown：指定向端口发送的命令字符串。 sever配置没什么可优化的。 name：指定service的名字。 service配置没什么可优化的。 port：指定服务器端要创建的端口号，并在这个端口监听来自客户端的请求 minProcessors：服务器启动时创建的处理请求的线程数 maxProcessors：最大可以创建的处理请求的线程数 enableLookups：如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址 redirectPort：指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号 acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理 maxConnections：达到这个值之后，将继续接受连接，但是不处理，能继续接受多少根据acceptCount的值 minSpareThreads：最小空闲线程数 connectionTimeout：指定超时的时间数(以毫秒为单位) 官网8.5版本connector使用连接类型如下： 查看Connector源码: 可知默认协议使用的是Http11NioProtocol，即NIO方式。 tomcat默认连接池有限制，可以为connector配置自己的连接池，例如： 在连接池中可以根据项目自定义最大线程数量。 name：属性用于日志和错误信息，在整个Server中应该唯一 defaultHost：defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配 没什么可优化的。 name：指定虚拟主机的主机名，一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配； 注：一般情况下，主机名需要是在DNS服务器中注册的网络名，但是Engine指定的defaultHost不需要 appBase：应用程序基本目录，即存放应用程序的目录 unpackWARs：指定了是否将war文件解压，如果为true，则通过解压后的目录运行该Web应用；如果为false，则直接使用WAR文件运行Web应用 autoDeploy：是否自动部署，Tomcat运行期间会用一个线程定时检查，如果有新的web工程会自动部署。 autoDeploy生产环境之下可以改成false，减少tomcat的负担。 autoDeploy有需要注意的点，如果为true，拷贝war到webapp下面，tomcat自动解压并部署。但是停掉tomcat拷贝新的war包过去，tomcat不会解压新包并后覆盖旧目录，因为tomcat直接使用了之前解压过的目录。官网有描述： If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded (note that the auto deployer, if enabled, will automatically expand the updated WAR file once the previously expanded directory is removed). docBase：代表应用程序或war文件存放的路径，这个可以自由指定，例如d:/study path： 表示此web应用程序的url的前缀，这样请求的url为 http://localhost:8080/path/ ** reloadable：如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib和/WEB-INF/classes目录的变化，自动装载新的应用程序，可以在不重起tomcat的情况下改变应用程序 生产环境中可以把reloadable设置为false。 className：指定Realm使用的类名，此类必须实现org.apache.catalina.Realm接口 没什么可优化的 className：规定了Valve的类型；例如tomcat默认的是AccessLogValve。 directory：指定日志存储的位置，默认日志存储在 TOMCAT_HOME/logs目录下，可以看到如下所示的日志文件。 没什么可优化的。 Tomcat内存优化主要是对 tomcat 启动参数优化，我们可以在 tomcat 的启动脚本 catalina.sh 中设置 java_OPTS 参数。 现公司服务器内存一般都可以加到最大2G ，所以可以采取以下配置： JAVA_OPTS=’-Xms1024m -Xmx2048m -XX: PermSize=256M -XX:MaxNewSize=256m -XX:MaxPermSize=256m’ 配置完成后可重启Tomcat ，通过以下命令进行查看配置是否生效： 首先查看Tomcat 进程号：sudo lsof -i:9027 我们可以看到Tomcat 进程号是 12222 。 查看是否配置生效：sudo jmap – heap 12222 我们可以看到MaxHeapSize 等参数已经生效。 在Tomcat 配置文件 server.xml 中的 <Connector port="9027" protocol="HTTP/1.1" maxHttpHeaderSize="8192" minProcessors="100" maxProcessors="1000" acceptCount="1000" redirectPort="8443" disableUploadTimeout="true"/> maxThreads 客户请求最大线程数 minSpareThreads Tomcat初始化时创建的 socket 线程数 maxSpareThreads Tomcat连接器的最大空闲 socket 线程数 enableLookups 若设为true, 则支持域名解析，可把 ip 地址解析为主机名 redirectPort 在需要基于安全通道的场合，把客户请求转发到基于SSL 的 redirectPort 端口 acceptAccount 监听端口队列最大数，满了之后客户请求会被拒绝（不能小于maxSpareThreads ） connectionTimeout 连接超时 minProcessors 服务器创建时的最小处理线程数 maxProcessors 服务器同时最大处理线程数 URIEncoding URL统一编码 compression 打开压缩功能 compressionMinSize 启用压缩的输出内容大小，这里面默认为2KB compressableMimeType 压缩类型 connectionTimeout 定义建立客户连接超时的时间. 如果为 -1, 表示不限制建立客户连接的时间
