Tomcat 隸屬于 Apache 基金會，是開源的輕量級 Web 應用服務器，使用非常廣泛。server.xml是 Tomcat 中最重要的配置文件，server.xml的每一個元素都對應了 Tomcat 中的一個組件；通過對 XML 文件中元素的配置，可以實現(xiàn)對 Tomcat 中各個組件的控制。因此，學習server.xml文件的配置，對于了解和使用 Tomcat 至關重要。

　　本文將通過實例，介紹server.xml中各個組件的配置，并詳細說明 Tomcat 各個核心組件的作用以及各個組件之間的相互關系。

　　說明：由于server.xml文件中元素與 Tomcat 中組件的對應關系，后文中為了描述方便，“元素”和“組件”的使用不嚴格區(qū)分。

2 server.xml配置實例

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

3 server.xml文檔的整體結構和元素分類

3.1 整體結構

　　server.xml的整體結構如下：

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

3.2 元素分類

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

第 1 類：頂層元素，和

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

第 2 類：連接器，

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

第 3 類：容器，、和

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

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

　　實際上，Server、Service、Connector、Engine、Host 和 Context 是最重要的最核心的 Tomcat 組件，其他組件都可以歸為內(nèi)嵌組件。下面將詳細介紹 Tomcat 中各個核心組件的作用，以及相互之間的關系。

4 核心組件

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

4.1 Server

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

　　在第一部分的例子中，在最外層有一個元素，shutdown屬性表示關閉 Server 的指令；port屬性表示 Server 接收shutdown指令的端口號，設為-1可以禁掉該端口。

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

4.2 Service

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

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

4.3 Connector

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

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

　　通過配置第 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 和客戶端之間加一層代理服務器（如 nginx），用于請求的轉發(fā)、負載均衡、處理靜態(tài)文件等；通過代理服務器訪問 Tomcat 時，是在局域網(wǎng)中，因此一般仍使用 8080 端口。

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

4.4 Engine

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

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

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

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

4.5 Host

4.5.1 Engine 與 Host

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

4.5.2 Host 的作用

　　Host 虛擬主機的作用，是運行多個 Web 應用（一個 Context 代表一個 Web 應用），并負責安裝、展開、啟動和結束每個 Web 應用。

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

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

4.5.3 Host 的配置

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

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

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

　　unpackWARs指定了是否將代表 Web 應用的 WAR 文件解壓；如果為true，通過解壓后的文件結構運行該 Web 應用，如果為false，直接使用 WAR 文件運行 Web 應用。

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

4.6 Context

4.6.1 Context 的作用

　　Context 元素代表在特定虛擬主機上運行的一個 Web 應用。在后文中，提到 Context、應用或 Web 應用，它們指代的都是 Web 應用。每個 Web 應用基于 WAR 文件，或 WAR 文件解壓后對應的目錄（這里稱為應用目錄）。Context 是 Host 的子容器，每個 Host 中可以定義任意多的 Context 元素。

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

4.6.2 Web 應用自動部署

第 1 點：Host 的配置

　　要開啟 Web 應用的自動部署，需要配置所在的虛擬主機；配置的方式就是前面提到的 Host 元素的deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設置為true，則 tomcat 啟動自動部署：當檢測到新的 Web 應用或 Web 應用的更新時，會觸發(fā)應用的部署（或重新部署）。二者的主要區(qū)別在于，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。

第 2 點：檢查 Web 應用更新

　　一個 Web 應用可能包括以下文件：XML 配置文件，WAR 包，以及一個應用目錄（該目錄包含 Web 應用的文件結構）；其中 XML 配置文件位于xmlBase指定的目錄，WAR 包和應用目錄位于appBase指定的目錄。Tomcat 按照如下的順序進行掃描，來檢查應用更新：

掃描虛擬主機指定的xmlBase下的 XML 配置文件；
掃描虛擬主機指定的appBase下的 WAR 文件；
掃描虛擬主機指定的appBase下的應用目錄。

第 3 點：元素的配置

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

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

　　path指定了訪問該 Web 應用的上下文路徑，當請求到來時，Tomcat 根據(jù) 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 應用時，發(fā)現(xiàn)了xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應用目錄，則該 Web 應用的path屬性是app1。如果名稱不是app1而是ROOT，則該 Web 應用是虛擬主機默認的 Web 應用，此時path屬性推導為""。

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

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

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

第 4 點：自動部署舉例

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

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

4.6.3 server.xml中靜態(tài)部署 Web 應用

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

docBase：靜態(tài)部署時，docBase可以在appBase目錄下，也可以不在；本例中，docBase不在appBase目錄下；
path：靜態(tài)部署時，可以顯式指定path屬性，但是仍然受到了嚴格的限制：只有當自動部署完全關閉（deployOnStartup和autoDeploy都為false）或docBase不在appBase中時，才可以設置path屬性。在本例中，docBase不在appBase中，因此path屬性可以設置；
reloadable屬性的用法與自動部署時相同。

5 核心組件的關聯(lián)

5.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 應用。

5.2 如何確定請求由誰處理？

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

5.2.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)通過不同的端口號來訪問同一臺機器上部署的不同應用。

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

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

5.2.3 根據(jù) URI 選定 Context/Web 應用

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

5.2.4 舉例

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

5.3 如何配置多個服務

　　通過在 Server 中配置多個 Service 服務，可以實現(xiàn)通過不同的端口號來訪問同一臺機器上部署的不同 Web 應用。在server.xml中配置多服務的方法非常簡單，分為以下幾步：

復制元素，放在當前后面；

修改端口號：根據(jù)需要監(jiān)聽的端口號修改元素的port屬性；必須確保該端口沒有被其他進程占用，否則 Tomcat 啟動時會報錯，而無法通過該端口訪問 Web 應用。
以 Win7 為例，可以用如下方法找出某個端口是否被其他進程占用：netstat -aon|findstr "8081"發(fā)現(xiàn) 8081 端口被 PID 為 2064 的進程占用，tasklist |findstr "2064"發(fā)現(xiàn)該進程為FrameworkService.exe（這是 McAfee 殺毒軟件的進程）。

修改 Service 和 Engine 的name屬性；

修改 Host 的appBase屬性（如webapps2）

Web 應用仍然使用自動部署；

將要部署的 Web 應用（WAR 包或應用目錄）拷貝到新的appBase下。

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

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

http://localhost:8080/docs/
http://localhost:8084/docs/

6 其他組件

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

6.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)高可擴展性、高性能，以及與本地服務器技術更好的集成。

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

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

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

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

6.2 GlobalNamingResources 與 Realm

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

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

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

6.3 Valve

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

單詞 Valve 的意思是“閥門”，在 Tomcat 中代表了請求處理流水線上的一個組件；Valve 可以與 Tomcat 的容器（Engine、Host 或 Context）關聯(lián)。不同的 Valve 有不同的特性，下面介紹一下本例中出現(xiàn)的 AccessLogValve。

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

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

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

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

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

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

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

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

%u：授權的遠程用戶名，如果沒有，則是-。

%t：訪問的時間。

%r：請求的第一行，即請求方法（Get/Post 等）、URI 及協(xié)議。

%s：響應狀態(tài)，200、404等等。

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

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

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

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