Tomcat的Server文件如何配置

這篇文章將為大家詳細講解有關(guān)Tomcat的Server文件如何配置，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

一、一個server.xml配置實例

server.xml位于$TOMCAT_HOME/conf目錄下;下面是一個server.xml實例。后文中將結(jié)合該實例講解server.xml中，各個元素的含義和作用;在閱讀后續(xù)章節(jié)過程中，可以對照該xml文檔便于理解。

二、server.xml文檔的元素分類和整體結(jié)構(gòu)

1、整體結(jié)構(gòu)

server.xml的整體結(jié)構(gòu)如下：

該結(jié)構(gòu)中只給出了Tomcat的核心組件，除了核心組件外，Tomcat還有一些其他組件，下面介紹一下組件的分類。

2、元素分類

server.xml文件中的元素可以分為以下4類：

(1)頂層元素：<Server>和<Service>

元素是整個配置文件的根元素，元素則代表一個Engine元素以及一組與之相連的Connector元素。

(2)連接器：<Connector>

代表了外部客戶端發(fā)送請求到特定Service的接口;同時也是外部客戶端從特定Service接收響應(yīng)的接口。

(3)容器：<Engine><Host><Context>

容器的功能是處理Connector接收進來的請求，并產(chǎn)生相應(yīng)的響應(yīng)。Engine、Host和Context都是容器，但它們不是平行的關(guān)系，而是父子關(guān)系：Engine包含Host，Host包含Context。一個Engine組件可以處理Service中的所有請求，一個Host組件可以處理發(fā)向一個特定虛擬主機的所有請求，一個Context組件可以處理一個特定Web應(yīng)用的所有請求。

(4)內(nèi)嵌組件：可以內(nèi)嵌到容器中的組件。

實際上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat組件，其他組件都可以歸為內(nèi)嵌組件。

下面將詳細介紹Tomcat中各個核心組件的作用，以及相互之間的關(guān)系。

三、核心組件

本部分將分別介紹各個核心組件的作用、特點以及配置方式等。

1、Server

Server元素在最頂層，代表整個Tomcat容器，因此它必須是server.xml中***一個最外層的元素。一個Server元素中可以有一個或多個Service元素。

在***部分的例子中，在最外層有一個元素，shutdown屬性表示關(guān)閉Server的指令;port屬性表示Server接收shutdown指令的端口號，設(shè)為-1可以禁掉該端口。

Server的主要任務(wù)，就是提供一個接口讓客戶端能夠訪問到這個Service集合，同時維護它所包含的所有的Service的聲明周期，包括如何初始化、如何結(jié)束服務(wù)、如何找到客戶端要訪問的Service。

2、Service

Service的作用，是在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務(wù)。一個Service可以包含多個Connector，但是只能包含一個Engine;其中Connector的作用是從客戶端接收請求，Engine的作用是處理接收進來的請求。

在***部分的例子中，Server中包含一個名稱為“Catalina”的Service。實際上，Tomcat可以提供多個Service，不同的Service監(jiān)聽不同的端口，后文會有介紹。

3、Connector

Connector的主要功能，是接收連接請求，創(chuàng)建Request和Response對象用于和請求端交換數(shù)據(jù);然后分配線程讓Engine來處理這個請求，并把產(chǎn)生的Request和Response對象傳給Engine。

通過配置Connector，可以控制請求Service的協(xié)議及端口號。在***部分的例子中，Service包含兩個Connector：

(1)通過配置第1個Connector，客戶端可以通過8080端口號使用http協(xié)議訪問Tomcat。其中，protocol屬性規(guī)定了請求的協(xié)議，port規(guī)定了請求的端口號，redirectPort表示當強制要求https而請求是http時，重定向至端口號為8443的Connector，connectionTimeout表示連接的超時時間。

在這個例子中，Tomcat監(jiān)聽HTTP請求，使用的是8080端口，而不是正式的80端口;實際上，在正式的生產(chǎn)環(huán)境中，Tomcat也常常監(jiān)聽8080端口，而不是80端口。這是因為在生產(chǎn)環(huán)境中，很少將Tomcat直接對外開放接收請求，而是在Tomcat和客戶端之間加一層代理服務(wù)器(如nginx)，用于請求的轉(zhuǎn)發(fā)、負載均衡、處理靜態(tài)文件等;通過代理服務(wù)器訪問Tomcat時，是在局域網(wǎng)中，因此一般仍使用8080端口。

(2)通過配置第2個Connector，客戶端可以通過8009端口號使用AJP協(xié)議訪問Tomcat。AJP協(xié)議負責(zé)和其他的HTTP服務(wù)器(如Apache)建立連接;在把Tomcat與其他HTTP服務(wù)器集成時，就需要用到這個連接器。之所以使用Tomcat和其他服務(wù)器集成，是因為Tomcat可以用作Servlet/JSP容器，但是對靜態(tài)資源的處理速度較慢，不如Apache和IIS等HTTP服務(wù)器;因此常常將Tomcat與Apache等集成，前者作Servlet容器，后者處理靜態(tài)資源，而AJP協(xié)議便負責(zé)Tomcat和Apache的連接。Tomcat與Apache等集成的原理如下圖。

關(guān)于Connector的更多內(nèi)容，可以參考我的另一篇文章：詳解tomcat的連接數(shù)與線程池

4、Engine

Engine組件在Service組件中有且只有一個;Engine是Service組件中的請求處理組件。Engine組件從一個或多個Connector中接收請求并處理，并將完成的響應(yīng)返回給Connector，最終傳遞給客戶端。

前面已經(jīng)提到過，Engine、Host和Context都是容器，但它們不是平行的關(guān)系，而是父子關(guān)系：Engine包含Host，Host包含Context。

在***部分的例子中，Engine的配置語句如下：

其中，name屬性用于日志和錯誤信息，在整個Server中應(yīng)該***。defaultHost屬性指定了默認的host名稱，當發(fā)往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進行處理;因此，defaultHost的值，必須與Engine中的一個Host組件的name屬性值匹配。

5、Host

(1)Engine與Host

Host是Engine的子容器。Engine組件中可以內(nèi)嵌1個或多個Host組件，每個Host組件代表Engine中的一個虛擬主機。Host組件至少有一個，且其中一個的name必須與Engine組件的defaultHost屬性相匹配。

(2)Host的作用

Host虛擬主機的作用，是運行多個Web應(yīng)用(一個Context代表一個Web應(yīng)用)，并負責(zé)安裝、展開、啟動和結(jié)束每個Web應(yīng)用。

Host組件代表的虛擬主機，對應(yīng)了服務(wù)器中一個網(wǎng)絡(luò)名實體(如”www.javastack.cn”，或IP地址”116.25.25.25”);為了使用戶可以通過網(wǎng)絡(luò)名連接Tomcat服務(wù)器，這個名字應(yīng)該在DNS服務(wù)器上注冊。

客戶端通常使用主機名來標識它們希望連接的服務(wù)器;該主機名也會包含在HTTP請求頭中。Tomcat從HTTP頭中提取出主機名，尋找名稱匹配的主機。如果沒有匹配，請求將發(fā)送至默認主機。因此默認主機不需要是在DNS服務(wù)器中注冊的網(wǎng)絡(luò)名，因為任何與所有Host名稱不匹配的請求，都會路由至默認主機。

(3)Host的配置

在***部分的例子中，Host的配置如下：

下面對其中配置的屬性進行說明：

name屬性指定虛擬主機的主機名，一個Engine中有且僅有一個Host組件的name屬性與Engine組件的defaultHost屬性相匹配;一般情況下，主機名需要是在DNS服務(wù)器中注冊的網(wǎng)絡(luò)名，但是Engine指定的defaultHost不需要，原因在前面已經(jīng)說明。

unpackWARs指定了是否將代表Web應(yīng)用的WAR文件解壓;如果為true，通過解壓后的文件結(jié)構(gòu)運行該Web應(yīng)用，如果為false，直接使用WAR文件運行Web應(yīng)用。

Host的autoDeploy和appBase屬性，與Host內(nèi)Web應(yīng)用的自動部署有關(guān);此外，本例中沒有出現(xiàn)的xmlBase和deployOnStartup屬性，也與Web應(yīng)用的自動部署有關(guān);將在下一節(jié)(Context)中介紹。

6、Context

(1)Context的作用

Context元素代表在特定虛擬主機上運行的一個Web應(yīng)用。在后文中，提到Context、應(yīng)用或Web應(yīng)用，它們指代的都是Web應(yīng)用。每個Web應(yīng)用基于WAR文件，或WAR文件解壓后對應(yīng)的目錄(這里稱為應(yīng)用目錄)。

Context是Host的子容器，每個Host中可以定義任意多的Context元素。

在***部分的例子中，可以看到server.xml配置文件中并沒有出現(xiàn)Context元素的配置。這是因為，Tomcat開啟了自動部署，Web應(yīng)用沒有在server.xml中配置靜態(tài)部署，而是由Tomcat通過特定的規(guī)則自動部署。下面介紹一下Tomcat自動部署Web應(yīng)用的機制。

(2)Web應(yīng)用自動部署

Host的配置

要開啟Web應(yīng)用的自動部署，需要配置所在的虛擬主機;配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設(shè)置為true，則tomcat啟動自動部署：當檢測到新的Web應(yīng)用或Web應(yīng)用的更新時，會觸發(fā)應(yīng)用的部署(或重新部署)。二者的主要區(qū)別在于，deployOnStartup為true時，Tomcat在啟動時檢查Web應(yīng)用，且檢測到的所有Web應(yīng)用視作新應(yīng)用;autoDeploy為true時，Tomcat在運行時定期檢查新的Web應(yīng)用或Web應(yīng)用的更新。除此之外，二者的處理相似。

通過配置deployOnStartup和autoDeploy可以開啟虛擬主機自動部署Web應(yīng)用;實際上，自動部署依賴于檢查是否有新的或更改過的Web應(yīng)用，而Host元素的appBase和xmlBase設(shè)置了檢查Web應(yīng)用更新的目錄。

其中，appBase屬性指定Web應(yīng)用所在的目錄，默認值是webapps，這是一個相對路徑，代表Tomcat根目錄下webapps文件夾。

xmlBase屬性指定Web應(yīng)用的XML配置文件所在的目錄，默認值為conf//，例如***部分的例子中，主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。

檢查Web應(yīng)用更新

一個Web應(yīng)用可能包括以下文件：XML配置文件，WAR包，以及一個應(yīng)用目錄(該目錄包含Web應(yīng)用的文件結(jié)構(gòu));其中XML配置文件位于xmlBase指定的目錄，WAR包和應(yīng)用目錄位于appBase指定的目錄。

Tomcat按照如下的順序進行掃描，來檢查應(yīng)用更新：

A、掃描虛擬主機指定的xmlBase下的XML配置文件

B、掃描虛擬主機指定的appBase下的WAR文件

C、掃描虛擬主機指定的appBase下的應(yīng)用目錄

元素的配置

Context元素最重要的屬性是docBase和path，此外reloadable屬性也比較常用。

docBase指定了該Web應(yīng)用使用的WAR包路徑，或應(yīng)用目錄。需要注意的是，在自動部署場景下(配置文件位于xmlBase中)，docBase不在appBase目錄中，才需要指定;如果docBase指定的WAR包或應(yīng)用目錄就在docBase中，則不需要指定，因為Tomcat會自動掃描appBase中的WAR包和應(yīng)用目錄，指定了反而會造成問題。

path指定了訪問該Web應(yīng)用的上下文路徑，當請求到來時，Tomcat根據(jù)Web應(yīng)用的  path屬性與URI的匹配程度來選擇Web應(yīng)用處理相應(yīng)請求。例如，Web應(yīng)用app1的path屬性是”/app1”，Web應(yīng)用app2的path屬性是”/app2”，那么請求/app1/index.html會交由app1來處理;而請求/app2/index.html會交由app2來處理。如果一個Context元素的path屬性為””，那么這個Context是虛擬主機的默認Web應(yīng)用;當請求的uri與所有的path都不匹配時，使用該默認Web應(yīng)用來處理。

但是，需要注意的是，在自動部署場景下(配置文件位于xmlBase中)，不能指定path屬性，path屬性由配置文件的文件名、WAR文件的文件名或應(yīng)用目錄的名稱自動推導(dǎo)出來。如掃描Web應(yīng)用時，發(fā)現(xiàn)了xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應(yīng)用目錄，則該Web應(yīng)用的path屬性是”app1”。如果名稱不是app1而是ROOT，則該Web應(yīng)用是虛擬主機默認的Web應(yīng)用，此時path屬性推導(dǎo)為””。

reloadable屬性指示tomcat是否在運行時監(jiān)控在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動。如果值為true，那么當class文件改動時，會觸發(fā)Web應(yīng)用的重新加載。在開發(fā)環(huán)境下，reloadable設(shè)置為true便于調(diào)試;但是在生產(chǎn)環(huán)境中設(shè)置為true會給服務(wù)器帶來性能壓力，因此reloadable參數(shù)的默認值為false。

下面來看自動部署時，xmlBase下的XML配置文件app1.xml的例子：

在該例子中，docBase位于Host的appBase目錄之外;path屬性沒有指定，而是根據(jù)app1.xml自動推導(dǎo)為”app1”;由于是在開發(fā)環(huán)境下，因此reloadable設(shè)置為true，便于開發(fā)調(diào)試。

自動部署舉例

最典型的自動部署，就是當我們安裝完Tomcat后，$TOMCAT_HOME/webapps目錄下有如下文件夾：

當我們啟動Tomcat后，可以使用http://localhost:8080/來訪問Tomcat，其實訪問的就是ROOT對應(yīng)的Web應(yīng)用;我們也可以通過http://localhost:8080/docs來訪問docs應(yīng)用，同理我們可以訪問examples/host-manager/manager這幾個Web應(yīng)用。

(3)server.xml中靜態(tài)部署Web應(yīng)用

除了自動部署，我們也可以在server.xml中通過元素靜態(tài)部署Web應(yīng)用。靜態(tài)部署與自動部署是可以共存的。在實際應(yīng)用中，并不推薦使用靜態(tài)部署，因為server.xml  是不可動態(tài)重加載的資源，服務(wù)器一旦啟動了以后，要修改這個文件，就得重啟服務(wù)器才能重新加載。而自動部署可以在Tomcat運行時通過定期的掃描來實現(xiàn)，不需要重啟服務(wù)器。

server.xml中使用Context元素配置Web應(yīng)用，Context元素應(yīng)該位于Host元素中。舉例如下

docBase：靜態(tài)部署時，docBase可以在appBase目錄下，也可以不在;本例中，docBase不在appBase目錄下。

path：靜態(tài)部署時，可以顯式指定path屬性，但是仍然受到了嚴格的限制：只有當自動部署完全關(guān)閉(deployOnStartup和autoDeploy都為false)或docBase不在appBase中時，才可以設(shè)置path屬性。在本例中，docBase不在appBase中，因此path屬性可以設(shè)置。

reloadable屬性的用法與自動部署時相同。

四、核心組件的關(guān)聯(lián)

1、整體關(guān)系

核心組件之間的整體關(guān)系，在上一部分有所介紹，這里總結(jié)一下：

Server元素在最頂層，代表整個Tomcat容器;一個Server元素中可以有一個或多個Service元素。

Service在Connector和Engine外面包了一層，把它們組裝在一起，對外提供服務(wù)。一個Service可以包含多個Connector，但是只能包含一個Engine;Connector接收請求，Engine處理請求。

Engine、Host和Context都是容器，且  Engine包含Host，Host包含Context。每個Host組件代表Engine中的一個虛擬主機;每個Context組件代表在特定Host上運行的一個Web應(yīng)用。

2、如何確定請求由誰處理?

當請求被發(fā)送到Tomcat所在的主機時，如何確定最終哪個Web應(yīng)用來處理該請求呢?

(1)根據(jù)協(xié)議和端口號選定Service和Engine

Service中的Connector組件可以接收特定端口的請求，因此，當Tomcat啟動時，Service組件就會監(jiān)聽特定的端口。在***部分的例子中，Catalina這個Service監(jiān)聽了8080端口(基于HTTP協(xié)議)和8009端口(基于AJP協(xié)議)。當請求進來時，Tomcat便可以根據(jù)協(xié)議和端口號選定處理請求的Service;Service一旦選定，Engine也就確定。

通過在Server中配置多個Service，可以實現(xiàn)通過不同的端口號來訪問同一臺機器上部署的不同應(yīng)用。

(2)根據(jù)域名或IP地址選定Host

Service確定后，Tomcat在Service中尋找名稱與域名/IP地址匹配的Host處理該請求。如果沒有找到，則使用Engine中指定的defaultHost來處理該請求。在***部分的例子中，由于只有一個Host(name屬性為localhost)，因此該Service/Engine的所有請求都交給該Host處理。

(3)根據(jù)URI選定Context/Web應(yīng)用

這一點在Context一節(jié)有詳細的說明：Tomcat根據(jù)應(yīng)用的 path屬性與URI的匹配程度來選擇Web應(yīng)用處理相應(yīng)請求，這里不再贅述。

(4)舉例

以請求http://localhost:8080/app1/index.html為例，首先通過協(xié)議和端口號(http和8080)選定Service;然后通過主機名(localhost)選定Host;然后通過uri(/app1/index.html)選定Web應(yīng)用。

3、如何配置多個服務(wù)

通過在Server中配置多個Service服務(wù)，可以實現(xiàn)通過不同的端口號來訪問同一臺機器上部署的不同Web應(yīng)用。

在server.xml中配置多服務(wù)的方法非常簡單，分為以下幾步：

(1)復(fù)制元素，放在當前后面。

(2)修改端口號：根據(jù)需要監(jiān)聽的端口號修改元素的port屬性;必須確保該端口沒有被其他進程占用，否則Tomcat啟動時會報錯，而無法通過該端口訪問Web應(yīng)用。

以Win7為例，可以用如下方法找出某個端口是否被其他進程占用：netstat -aon|findstr  "8081"發(fā)現(xiàn)8081端口被PID為2064的進程占用，tasklist |findstr  "2064"發(fā)現(xiàn)該進程為FrameworkService.exe(這是McAfee殺毒軟件的進程)。

(3)修改Service和Engine的name屬性

(4)修改Host的appBase屬性(如webapps2)

(5)Web應(yīng)用仍然使用自動部署

(6)將要部署的Web應(yīng)用(WAR包或應(yīng)用目錄)拷貝到新的appBase下。

以***部分的server.xml為例，多個Service的配置如下：

再將原webapps下的docs目錄拷貝到webapps2中，則通過如下兩個接口都可以訪問docs應(yīng)用：

http://localhost:8080/docs/

http://localhost:8084/docs/

五、其他組件

除核心組件外，server.xml中還可以配置很多其他組件。下面只介紹***部分例子中出現(xiàn)的組件，如果要了解更多內(nèi)容，可以查看Tomcat官方文檔。

1、Listener

Listener(即監(jiān)聽器)定義的組件，可以在特定事件發(fā)生時執(zhí)行特定的操作;被監(jiān)聽的事件通常是Tomcat的啟動和停止。

監(jiān)聽器可以在Server、Engine、Host或Context中，本例中的監(jiān)聽器都是在Server中。實際上，本例中定義的6個監(jiān)聽器，都只能存在于Server組件中。監(jiān)聽器不允許內(nèi)嵌其他組件。

監(jiān)聽器需要配置的最重要的屬性是className，該屬性規(guī)定了監(jiān)聽器的具體實現(xiàn)類，該類必須實現(xiàn)了org.apache.catalina.LifecycleListener接口。

下面依次介紹例子中配置的監(jiān)聽器：

VersionLoggerListener：當Tomcat啟動時，該監(jiān)聽器記錄Tomcat、Java和操作系統(tǒng)的信息。該監(jiān)聽器必須是配置的***個監(jiān)聽器。

AprLifecycleListener：Tomcat啟動時，檢查APR庫，如果存在則加載。APR，即Apache Portable  Runtime，是Apache可移植運行庫，可以實現(xiàn)高可擴展性、高性能，以及與本地服務(wù)器技術(shù)更好的集成。

JasperListener：在Web應(yīng)用啟動之前初始化Jasper，Jasper是JSP引擎，把JVM不認識的JSP文件解析成java文件，然后編譯成class文件供JVM使用。

JreMemoryLeakPreventionListener：與類加載器導(dǎo)致的內(nèi)存泄露有關(guān)。

GlobalResourcesLifecycleListener：通過該監(jiān)聽器，初始化<  GlobalNamingResources>標簽中定義的全局JNDI資源;如果沒有該監(jiān)聽器，任何全局資源都不能使用。<  GlobalNamingResources>將在后文介紹。

ThreadLocalLeakPreventionListener：當Web應(yīng)用因thread-local導(dǎo)致的內(nèi)存泄露而要停止時，該監(jiān)聽器會觸發(fā)線程池中線程的更新。當線程執(zhí)行完任務(wù)被收回線程池時，活躍線程會一個一個的更新。只有當Web應(yīng)用(即Context元素)的renewThreadsWhenStoppingContext屬性設(shè)置為true時，該監(jiān)聽器才有效。

2、GlobalNamingResources與Realm

***部分的例子中，Engine組件下定義了Realm組件：

Realm，可以把它理解成“域”;Realm提供了一種用戶密碼與web應(yīng)用的映射關(guān)系，從而達到角色安全管理的作用。在本例中，Realm的配置使用name為UserDatabase的資源實現(xiàn)。而該資源在Server元素中使用GlobalNamingResources配置：

GlobalNamingResources元素定義了全局資源，通過配置可以看出，該配置是通過讀取$TOMCAT_HOME/  conf/tomcat-users.xml實現(xiàn)的。

關(guān)于Tomcat域管理的更多內(nèi)容，可以參考：Realm域管理

3、Valve

在***部分的例子中，Host元素內(nèi)定義了Valve組件：

單詞Valve的意思是“閥門”，在Tomcat中代表了請求處理流水線上的一個組件;Valve可以與Tomcat的容器(Engine、Host或Context)關(guān)聯(lián)。

不同的Valve有不同的特性，下面介紹一下本例中出現(xiàn)的AccessLogValve。

AccessLogValve的作用是通過日志記錄其所在的容器中處理的所有請求，在本例中，Valve放在Host下，便可以記錄該Host處理的所有請求。AccessLogValve記錄的日志就是訪問日志，每天的請求會寫到一個日志文件里。AccessLogValve可以與Engine、Host或Context關(guān)聯(lián);在本例中，只有一個Engine，Engine下只有一個Host，Host下只有一個Context，因此AccessLogValve放在三個容器下的作用其實是類似的。

本例的AccessLogValve屬性的配置，使用的是默認的配置;下面介紹AccessLogValve中各個屬性的作用：

(1)className：規(guī)定了Valve的類型，是最重要的屬性;本例中，通過該屬性規(guī)定了這是一個AccessLogValve。

(2)directory：指定日志存儲的位置，本例中，日志存儲在$TOMCAT_HOME/logs目錄下。

(3)prefix：指定了日志文件的前綴。

(4)suffix：指定了日志文件的后綴。通過directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目錄下，可以看到如下所示的日志文件。

(5)pattern：指定記錄日志的格式，本例中各項的含義如下：

%h：遠程主機名或IP地址;如果有nginx等反向代理服務(wù)器進行請求分發(fā)，該主機名/IP地址代表的是nginx，否則代表的是客戶端。后面遠程的含義與之類似，不再解釋。

%l：遠程邏輯用戶名，一律是”-”，可以忽略。

%u：授權(quán)的遠程用戶名，如果沒有，則是”-”。

%t：訪問的時間。

%r：請求的***行，即請求方法(get/post等)、uri、及協(xié)議。

%s：響應(yīng)狀態(tài)，200,404等等。

%b：響應(yīng)的數(shù)據(jù)量，不包括請求頭，如果為0，則是””-。

例如，下面是訪問日志中的一條記錄：

pattern的配置中，除了上述各項，還有一個非常常用的選項是%D，含義是請求處理的時間(單位是毫秒)，對于統(tǒng)計分析請求的處理速度幫助很大。

開發(fā)人員可以充分利用訪問日志，來分析問題、優(yōu)化應(yīng)用。例如，分析訪問日志中各個接口被訪問的比例，不僅可以為需求和運營人員提供數(shù)據(jù)支持，還可以使自己的優(yōu)化有的放矢;分析訪問日志中各個請求的響應(yīng)狀態(tài)碼，可以知道服務(wù)器請求的成功率，并找出有問題的請求;分析訪問日志中各個請求的響應(yīng)時間，可以找出慢請求，并根據(jù)需要進行響應(yīng)時間的優(yōu)化。

關(guān)于“Tomcat的Server文件如何配置”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學(xué)到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。