漲薪技術|0到1學會性能測試第53課-Tomcat配置

前面的推文我們掌握了Tomcat伺服器的3種監控技術知識。今天給大家分享Tomcat調優技術。後續文章都會系統分享幹貨，帶大家從0到1學會性能測試，另外還有教程等同步資料，文末加小編VX：flyhappy111領取即可。

01Tomcat配置

當Tomcat伺服器安裝好并開始運作後，需要對伺服器進行一些基本配置，通常關于Tomcat伺服器的配置包括兩部分：

第一：編輯Tomcat的XML配置檔案;

第二：确定适當的環境變量;

1) XML配置檔案

關于XML配置檔案，Tomcat伺服器有兩個很重要的XML配置檔案需要配置：server.xml和web.xml。通常情況下這兩個檔案存放Tomcat安裝目錄下的conf檔案夾中。

server.xml檔案是Tomcat最主要的配置檔案，該檔案主要是指定Tomcat啟動時的初時配置，并定義Tomcat啟動和建構的方式。server.xml檔案中包含五類基本類别：頂層元素、連接配接器、容器、嵌套元件和全局設定。這些類别都有着很多屬性，在配置過程中可以對這些值進行微調，通常包括以下幾部分的内容：

• 頂層元素(Top Level Elements)

關于頂層元素主要包括伺服器和服務兩類，伺服器主要定義一個單個的Tomcat伺服器，主要包括Logger和ContextManager配置，此外還包括伺服器支援的“端口”、“關機”和“類名”屬性。服務則是一個元素，該元素嵌套在一個伺服器中，服務包含一個或多個用于共享相同引擎的元件，該元件主要功能是定義一個單一伺服器的元件，服務的名稱在“name”屬性中指定。

• 連接配接器(Connectors)

在伺服器标簽中可以定義一個或多個連接配接器，通過Catalina從這些端口向引擎元件發送請求，Tomcat允許定義HTTP和AJP兩種連接配接器，關于這兩種連接配接器将在連接配接器部分的内容中進行詳細介紹。

• 容器(Containers)

這些元素使用Catalina直接處理裝置的請求。

• 上下文(Context)

此元素是一個單一的web應用，并且包含如果查找到最适合的應用程式資源的路徑資訊，當Catalina接收到一個請求後，它使用context去比對最長的URL，直到找到正确的服務請求元素，context元素為每個元素設定一個最大的嵌套執行個體，雖然可以通過修改server.xml檔案來修改context的内容，但一般情況下不應該修改context内容，因為這些配置如果不重新開機Tomcat伺服器不能被加載。

• 主機(Host)

這個元素嵌套在引擎元素中，用于關聯Catalina伺服器所在網絡中的網絡伺服器名，這個元素的功能隻有在虛拟機注冊DNS管理域的過程中才能正确使用，該元素最大的作用是嵌套别名，可以為同一個虛拟機定義多個不同的别名。

• 叢集(Cluster)

叢集元素能夠提供上下文屬性複制、WAR部署、會話複制并且将其嵌套在一個引擎或主機元素中，雖然可以對這個元素進行配置，但一般情況下預設設定就可以滿足使用者的需求。

• 全局命名資源(Global Naming Resources)

這個元素主要是為一個指定伺服器指定全局Java名和目錄接口資源，可以在該元素中定義和的查找特征并且可以使用進行連結。如果使用該技術定義其它的參數，那麼必須指定和配置對象屬性。

• 範圍(Realm)

這個元素可以被嵌套在任何容器元素中，用于定義資料庫使用者名、密碼和容器的角色，如果嵌套在主機或引擎元素中，那麼Realm元素的特征将會繼承低級别容器的特性。Realm元素中最生要的屬性是“classmate”，其主要提供不同類型容器的安全性，并且實作的方式有多種。

• 資源(Resources)

這個元素主要是用于通過web應用程式引導Catalina的靜态資源，常見的靜态資源有：類、HTML和JSP檔案等。

• Web.xml檔案

Web.xml檔案遵從Servlet規範，其主要包含的資訊用于部署和配置web應用程式，如果是第一次配置Tomcat，那麼主要是定義Servlet映射到主要的部件(如JSP)。在Tomcat中，這個檔案以同樣的方式在Servlet規範中描述這些功能。

2) 環境變量

在第一次配置Tomcat時，有幾個環境需要進行适當的修改，主要包括：JAVA_OPTS、CATALINA_HOME、CATALINA_OPTS。

JAVA_OPTS

使用該變量可以定義JVM中堆的大小，堆大小是一個很重要的名額，當在部署一個新的應用程式時，需要設定一個适當的堆大小的值，否則會影響系統性能，同時可以消除或減小OOME消息。

CATALINA_HOME

該變量用于指定Tomcat的安裝位置，當Tomcat腳本啟動時會自動去檢查這個變量的值，以确定設定是否正确，避免運作過程中出現問題。

CATALINA_OPTS

該變量用于設定Tomcat指定的不同的選項。

除了以上一些配置外，還有兩個相關的配置會影響系統性能：DNS查找和JSP編譯。

DNS查找

如果web應用伺服器需要獲得用戶端的日志資訊，那麼通常有兩種方式：

一是：記錄用戶端機器的IP位址;

二是：在DNS中查找用戶端主機名資訊;

而DNS查詢需要網絡流量，在查詢過程中可能會經曆多個伺服器的往返查找，但也可能不需要，這樣就會導緻出現延遲響應的情況，如果需要消除這些延遲響應，就必須關閉DNS查詢，在HTTP對象中有一個getRemoteHost的方法，通過這個方法可以找到一個唯一的IP位址，關于DNS的選項設定在server.xml檔案中的connector(連接配接器)中設定，源代碼如下：

<!-- 
  Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 
-->
<Connector 
    className="org.apache.coyote.tomcat4.CoyoteConnector"
    port="8080" minProcessors="5" maxProcessors="75"
    enableLookups="true" redirectPort="8443"
    acceptCount="10" debug="0" connectionTimeout="20000"
    useURIValidationHack="false" 
/>           

如果需要關閉DNS查找，那麼将該選項設定為“false”。除非需要指定一個完整的主機名去通路網站，否則都需要将該選項設定為“false”，這樣不但可以節約帶寬、查找時間和記憶體。當然對于低流量的網站，這個設定項可能不會有明顯的效果，但是不能排除它某天變成了一個高流量的網站。

JSP編譯

在一個JSP頁面第一次被通路時，它需要轉換為Java servlet源碼，并且編譯在JAVA位元組碼，而當許多不同使用者同時通路JSP頁面時，伺服器可能會被處于一種高負載狀态，是以應該改善網站對JSP頁面的處理方法，進而優化JSP的性能。

1) Tomcat如何處理JSP頁面

JSP是Java servlet代碼與HTML标記的組合，Tomcat處理JSP是使用一個稱為Jasper 2的引擎，該引擎包括各種處理和解析JSP的元件，以及JSP的編譯器。在一個JSP頁面第一次被通路時，Jasper引擎會将源碼轉換為Java servlet源碼，并且使用JAVA編譯器将其編譯成JAVA位元組碼。

2) 稽核動态内容

JSP性能改進的第一步是采取分析網站的結構、預期負載和JSP頁面需要實作的功能，如果建立的網站中混雜着動态和靜态，當網站可以完成定期更新靜态内容時，那麼應該是動态處理結束後才多的去處理靜态内容，例如網站的标題，這是一個動态的内容，但是一天可能才處理一兩次。

現在解決動态稽核問題不完全是使用，現在有一些開源于JAVA模闆來解決這個問題(如Velocity或Freemarker)，在未來可能會成為一個新的功能。

3) JSP預編譯技術

當伺服器運作JSP頁面時伺服器會使用最大的性能來編譯JSP頁面，如果緩解這一問題，一般會對JSP進行預編譯操作，而不是等運作時才進行實時的編譯。通常有以下三種預編譯的方法來提高系統的性能。

第一：使用請求進行預編譯

預編譯的一次最簡單的方法是，在發送請求的過程中進行預編譯，因為在第一次發送請求時，JSP會自動進行編譯，這樣在第一個真實的使用者通路該JSP頁面時就不需要再編譯了，如果隻少數JSP頁面，并且不需要頻繁的啟動伺服器，這樣可以在伺服器啟動時，使用一個小腳本自動爬行所有的JSP頁面，這樣可以大大的提高性能。這個方法在開發過程中很有用，因為這種方法可以查找是那些使用者第一時間通路JSP頁面，并且可以糾正一些錯誤。

第二：啟動時進行預編譯

JAVA中有一個Java servlet的子產品，它包括JSP指定的一些功能和文法元素，這些文法在Web應用程式啟動時會指定JSP進行編譯，在“WEB-INF/web.xml”檔案中可以對JSP進行預編譯設定，如以下執行個體：

<web-app ...>
 <servlet>
  <servlet-name> YourJSP.jsp </servlet-name>
  <jsp-file> /path/to/yourjsp.jsp </servlet-name>
  <load-on-startup> 1 </load-on-startup>
 </servlet>  
</web-app>           

整數“1”是用來指定編譯序順的，是以可以為預編譯建立一個層次結構，這樣可以消除第一個使用者通路預編譯頁面的時間延遲，降低web程式重新開機的所需要的資源。

第三：在編譯過程中進行預編譯

在編譯過程中進行預編譯是指在建構Web應用程式時，使用JspC進行預編譯JSP代碼，而不是在Tomcat伺服器上進行動态編譯，在一些情況中下這種技術可以提高4%的系統性能。

JSP最佳實踐

前面介紹了通過修改Tomcat配置檔案來提高JSP性能，而遵守一些編碼規則也可以提高JSP的性能，通常有兩種方法：高效緩存和對象控制。

第一：在代碼中如何有效提高JSP原始的緩存資料可以有效的提高性能，即如何有效的利用緩存中的資料或如何高效使用緩存方法來處理資料。

第二：目标控制，主要包括會話長度/範圍、線程池配置和緩存區大小。

1) JSP資料緩存

如果JSP頁面已經産生了一些靜态或動态内容，那麼這種情況不要它再出現，因為它可以通過會話或應用程式調用緩存資料，為了得到安全的動态内容，這樣會重複使用所有活動會話。

生成靜态檔案使用了一次_jsplnit()方法，同時使用_jspService方法對資料進行備份，但不在每次請求頁面時使用out.print()。緩存中的動态資料有4個持久機制，Tomcat原始的持久機制、cookies、URL重寫和隐藏區域。

通常的一個解決方案是，平衡用戶端和伺服器間的負載、安全緩存(Tomcat持續支援安全的存儲資料)和處理隐藏區域。

2) 對象控制

在關閉會話、重新使用标簽和配置緩存區時，很容易浪費伺服器CPU時間周期，特别是在清理JSP代碼時需要考慮這個問題，是以可以考慮移除大資料和關閉會話、對象。在整個頁面生成過程中一次性移除大資料(如圖檔)，通常使用flush()方法移除，并且應該考慮設定緩存大小。在控制對象時，JSP包括處理會話、孤立對象和饑餓記憶體的處理機制，如逾時和序列化。

02連接配接器配置

接連器元素是Tomcat用于連接配接外部程式的，其允許Catalina接受請求，傳送到Web應用程式，将生成的動态資訊通過連接配接器傳回到Tomcat伺服器。

Tomcat的連接配接器包括兩種：HTTP和AJP。

每個連接配接器元素都有一個端口，Tomcat會通過這個端口來監聽請求，并且會為伺服器和引擎中的連接配接器元素設定等級，這樣管理者可以通過建立邏輯結構來管理這些資料流。此外，使用者的請求通過路由器可以找到相應的伺服器，連接配接器通過連接配接可以将Tomcat與其它web技術進行連接配接(如Apache伺服器)，這樣可以有效平衡負載。

連接配接器元素隻有一件事，就是監聽請求，并通過引擎獲得指定端口上傳回的結果。就它本身來說，這個連接配接器自身沒什麼功效，這個元素包含的唯一資訊是輸入和輸出的端口，以及一些告訴它如何準确輸入和輸出的特性。

那麼如何通過嵌套連接配接器來實作我們需要的功能呢?下面是一個例子：

<Server>
  <Service>
    <Connector port="8443"/>
    <Connector port="8444"/>
    <Engine>
      <Host name="yourhostname">
        <Context path="/webapp1"/>
        <Context path="/webapp2"/>
      </Host>
    </Engine>
  </Service>
</Server>           

上例中定義了兩個連接配接元素，監聽的兩個端口号為8443和8444，但需要注意的是每個作業系統每個連接配接器隻允許一個端口，是以每個邊接器需要為自己定義一個指定的端口。并且這兩個連接配接器元素都嵌套在一個伺服器元素中，這樣可以告訴連接配接器如何監聽指定的端口，并且通過伺服器的引擎連接配接器可以處理這些請求并将處理後的結果傳回到連接配接器。

根據該例設定，這兩個連接配接器都是使用相同的引擎發送請求，同樣反過來，也是通過這個引擎來獲得Web應用程式傳回的結果。

如果現在想修改目前配置，不需要每個連接配接器傳回的請求有兩個響應，隻需要每個連接配接器傳回其指定的端口資訊，要實作該功能，隻要對配置進行如下修改即可：

<Server>
  <Service name="Catalina">
    <Connector port="8443"/>
    <Engine>
      <Host name="yourhostname">
        <Context path="/webapp1"/>
      </Host>
    </Engine>
  </Service>
  <Service name="Catalina8444">
    <Connector port="8444"/>
    <Engine>
      <Host name="yourhostname">
        <Context path="/webapp2"/>
      </Host>
    </Engine>
  </Service>
</Server>           

該例中使用了兩個不同的服務，使用兩個不同的連接配接器，通過連接配接器中兩個不同端口和引擎連接配接到同一台伺服器，雖然變的複雜了，但是層次結構更簡單。

HTTP連接配接器

雖然Tomcat設計了一個servlet容器，但其它功能隻能适用于一個獨立的Web伺服器，而servlet容器的這些功能HTTP連接配接器也可以實作。HTTP連接配接器使用HTTP/1.1協定，它代表一個單獨的連接配接器元件，監聽一個給定的伺服器上指定的TCP端口的連接配接。

連接配接器有很多屬性，通過修改之些屬性可以精确的指定它的功能，并且可以對功能進行受權，如代理和重定向。其兩個最重要的屬性是“協定”和“SSLEnabled”。

“協定”屬性主要定義連接配接器使用的通信協定，預設的通信協定為HTTP/1.1，但可以對通信協定進行修改，并且允許設定更多的其它的協定。例如，希望調整socket的性能，可以将“協定”屬性項設定為NIO(Java New IO簡稱)協定。如果将“SSLEnabled”屬性設定為“True”連接配接器會使用SSL握手、SSL加密和SSL解密。

HTTP連接配接器也可以作用為負載均衡的一種解決方案，配合HTTP負載平衡器可以支援粘性會話，如mod_proxy方法，但是如果處理代理的情況AJP連接配接器比HTTP連接配接器效果更好。

AJP連接配接器

AJP連接配接器的工作方式與HTTP連接配接器的方式一樣，但其使用的協定為AJP協定，Apache JServ協定或AJP協定，AJP協定是一個優化的二進制版本的協定，通常用于Tomcat伺服器與Apache Web應用程式進行通訊。

AJP連接配接器通常使用在Tomcat的插件技術mod_jk中，也可以重新已無效的mod_jserv插件，并且通常JK庫函數可以支援更多的協定和Tomcat的指定功能。AJP連接配接器功能通常需要一個高流量的系統支援，通常是叢集的web系統。其允許Apache伺服器提供靜态内容和代理請求，目的是讓整個網絡負載更平均，這樣可以讓Tomcat伺服器更專注于處理動态内容。

Connerctor參數配置

以下代碼是連接配接器配置的一個執行個體：

<Connector executor="tomcatThreadPool"
               port="80" protocol="HTTP/1.1"
               connectionTimeout="50000"
               keepAliveTimeout="20000"
               maxKeepAliveRequests="1"
               redirectPort="444"
               maxHttpHeaderSize="8192" URIEncoding="UTF-8" enableLookups="false" acceptCount="100" disableUploadTimeout="true"/>           

常見連接配接器參數如下：

connectionTimeout：網絡連接配接逾時時間，機關為毫秒，如果設定為“0”則表示永不逾時，不建議這樣設定;

keepAliveTimeout：保持連接配接的最長時間，機關為毫秒;

maxKeepAliveRequests：最大的連接配接數(“1”表示禁用該設定，“-1”表示不限制個數，預設值為100);

maxHttpHeaderSize：表示允許的HTTP請求頭的最大值，超過此大小的請求将不予受理;

URIEncoding：設定Tomcat容器的URL編碼格式;

acceptCount：指定當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求将不予處理，預設為10個;

disableUploadTimeout：上傳檔案時是否使用逾時機制;

enableLookups：是否啟動反查域名機制(取值為true或false)，為了提高處理能力，應設定為false;

bufferSize：定義連接配接器所提供的輸入流中緩存區大小，預設值為2048個位元組;

maxSpareThreads：最大空閑連接配接數，如果建立的線程超過這個值，Tomcat就會關閉不再需要的線程數，預設值為50;

maxThreads：最多同時處理的連接配接數，Tomcat使用線程來處理接收的每個請求，這個值表示Tomcat可建立的最大的線程數;

minSpareThreads：最小空閑線程數，Tomcat初始化時建立的線程數，該值應該少于maxThreads，預設值為4;

minProcessors：最小空閑連接配接線程數，預設值為10;

maxProcessors：最大連接配接線程數，預設值為75;

下面詳細介紹maxThreads、connectionTimeout和acceptCount這個參數：

一、maxThreads配置

maxThreads代表Tomcat的HTTP連接配接器所建立的請求處理線程的最大數目，如以下代碼：

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="250" minSpareThreads="20" maxIdleTime="60000" />
<Connector executor="tomcatThreadPool"
               port="80" protocol="HTTP/1.1"
               connectionTimeout="60000"
               keepAliveTimeout="15000"
               maxKeepAliveRequests="1"
               redirectPort="443"
               ....../>           

如上例表示Tomcat伺服器最大榀以處理250個請求，如果不設定該值，那預設值為200。

maxThreads處理過程如下：

1) 當伺服器啟動時，HTTP連接配接器将建立一個基礎線程數，這個值為minSpareThreads(最小空閑連接配接數);

2) 每個傳入的請求都需要一個持續時間，允許的最大時間為keepAliveTimeout所設定的值;

3) 如果需要同時處理的請求數超過minSpareThreads設定的值，那麼額外的線程數将以最大配置數為準，即maxThreads的值;

4) 如果同時處理的請求數超過最大配置值，即超過maxThreads所設定的值，那麼這麼請求将會排成隊列，隊列最大值由acceptCount确定;

5) 如果隊列長度超過acceptCount所設定的值，那麼請求連接配接時将會被拒絕，直到有可用資源時才建立連接配接;

maxThreads是一個很重要的參數，那麼在配置過程它應該遵守什麼原則呢?

org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status           

如果出現上述的錯誤，那麼首先需要調查請求所花費的時間，并檢查它是否傳回線程池，例如，資料庫連接配接一直不釋放，那麼線程需要等獲得資料庫連接配接後才能運作，這樣導緻其它的請求不能被處理，如果此時增大maxThreads值，可以會導緻以下後果：

--消耗大量記憶體;

--在切換上下文内容時所花費的時間将會進一步增多;

這些元素使用Catalina直接處理裝置的請求。

是以，如果在優化系統性能過程中，将該設定高達500-750了，那麼這樣将帶來上述兩個問題，是以maxThreads的值大于750，那麼則需要使用Tomcat伺服器叢集來解決這個問題，如需要将maxThreads的值設定為1000，那麼需要使用兩個Tomcat伺服器，各自設定為500，而不是将一個Tomcat伺服器設定為500。

connectionTimeout配置

connectionTimeout用于設定網絡連接配接逾時時間。設定通訊的逾時時間對于改善通訊過程非常重要，它可以幫助發現問題和穩定分布系統，JK有幾種不同的逾時類型，按屬性分，通常包括：CPing/CPong、低級别TCP逾時、連接配接池和空閑逾時、防火牆連接配接和回複逾時，通常在httpd.conf、workers.properties和server.xml三個檔案中進行設定，也可以分别對這些選項進行設定。但這些選項預設情況是禁用狀态，一般不設定逾時的極端值，否則可能适得其反。

1) CPing/CPong

CPing/CPong用于測試後端小資料包的狀态，在建立連接配接後和請求傳回資料包之前JK可以直接測試資料包，可以通常配置來設定CPong與CPing之間最大空閑時間。

在ping_mode子產品中可以設定不種連接配接方式的逾時時間：

連接配接模式(connect mode)：使用connect_timeout屬性設定逾時時間;

前崗模式(prepost mode)：使用prepost_timeout屬性設定逾時時間;

間隔模式(interval mode)：使用connection_ping_interval屬性設定空閑間隔時間;

2) 低級别TCP逾時

一些平台允許設定TCP套接字操作逾時，這種情況隻允許在Linux和Windows作業系統中使用，其它的平台不支援，如果平台TCP發送和接受逾時，那麼可以通過socket_timeout屬性進行設定，該屬性在檔案workers.properties中。如果平台不支援套接字操作逾時，JK也會接受這個屬性，但這種情況下，該屬性沒有任何效果，預設值為“0”，表示禁用逾時，該屬性的機關為秒，而非毫秒，這個逾時是一個低層次的，用于套接字中每個讀與寫的操作。

使用此屬性JK可以很快的反應關于網絡類型的問題，但這也有一些負影響，因為平台太多，如果真的是由于網絡問題引起的逾時，或者沒有收到後端傳回的資料包，那麼JK不可能很快的恢複，故不可能将這個值設定的太小。

一般情況下當建立連接配接後，可以使用socket_connect_timeout來測試逾時時間，其機關為毫秒，因為一些平台不支援socket_timeout，逾時時間一般設定為1000至5000毫秒。

3) 連接配接池和空閑逾時

JK會處理每個Web伺服器連接配接池中的每個連接配接，會連接配接被用于持久模式，當一個請求處理完成後，連接配接會處于斷開狀态，等待下一個發送過來的請求，連接配接池希望增加并行請求的數量。

大多數應用程式每個時間段所承受的負載是有所不同的，是以當連接配接數在不斷的增加時，連接配接會被臨時儲存在後端，這樣導緻前端越來越擁擠，是以後端可能會使用一個線程來處理送出的新的連接配接，是以如果當系統負載減少時可以将連接配接池縮小。

JK允許在連接配接池的一些連接配接在一些空閑時間後被關閉，使用connection_pool_timeout屬性可以設定最大空閑時間，機關為秒，其預設值為“0”，表示禁止關閉空閑連接配接。一般建議設定為10分鐘，即600秒。如果需要設定此屬性，那麼在Tomcat伺服器中server.xml配置檔案中的AJP連接配接器中修改connectionTimeout選項，機關為毫秒。

JK并不會立即關閉那些逾時的連接配接，而是先運作一些内部自動維護的任務，每隔60秒自動檢查所有空閑狀态的連接配接，60秒的時間間隔可以使用全局屬性(worker.maintain)進行重新設定，但不建議修改該值。

4) 防火牆連接配接

空閑連接配接來自于防火牆，這往往是在網絡伺服器和後端之間，如果連接配接長時間處于閑置狀态，那麼連接配接的狀态表将會丢失，TCP是一個可靠的協定，它會檢測TCP ACKs是否丢失，并且會重新發送那些時間相對較長的包，當然這一般需要幾分鐘的時間。是以JK配置時常常需要配置connection_pool_timeount

和connection_pool_minsize兩個屬性，Tomcat測試需要配置connectionTimeout屬性來防止空閑連接配接下降。

另外，使用可以配置socket_keepalive标準套接字選項，這樣當連接配接處于空閑狀态時，會自動向每個連接配接發送TCP keepalive包，預設值為“False”，如果懷疑是防火牆引用的空閑連接配接，那麼可以将該選項設定為“True”。但是對于不同的平台，預設的時間間隔和算法是不一緻的，是以要調整TCP的設定項來測試其控制TCP keepalive的效果。

5) 回複逾時

對于請求的響應JK也可能出現逾時的情況，出現逾時的響應不能被處理，反之一樣，連接配接響應的資料包需要多長時間才能完成，這是我們關注的問題，例如一個長時間的下載下傳，無法設定一個全局的回複逾時的時間，因為無法确定最後下載下傳的時間。

通過設定replay_timeout屬性可以設定逾時時間，機關為毫秒，預設值為“0”，表示不禁用逾時，如以下配置：

worker.worker1.port = 8888
worker.worker1.reply_timeout = 120000
worker.worker1.socket_timeout = 150000           

該配置在workers.properties檔案中設定。

配合Apache一起使用時，可以通過設定http的環境變量reply_timeout來設定逾時時間，這樣更靈活。

acceptCount配置

acceptCount是指當所有可以使用的處理請求的線程數都被使用時，可以放到處理隊列中的請求數，超過這個數的請求将不予處理，預設為10個，即允許請求隊列的最大長度，如果用戶端送出的請求不能被同時并發處理完成，即用戶端請求數超過maxThreads的值，那麼其餘的請求将會以隊列的方式存儲着，如果這個隊列的長度大于acceptCount所設定的值，那麼用戶端送出的請求就不會被處理，即被伺服器拒絕，導緻連接配接失敗。

在設定該值時應該注意，這個值不能設定的太小也不能設定的太大，如果設定的太小會出現大量請求可能被直接拒絕的情況，但其它此時這些請求可能根本沒有逾時;如果将該值設定的過大，則會出現請求被逾時的情況，因為如果排的隊列過長，這樣後面的隊列很可能出現逾時的情況，keepAliveTimeout和connectionTimeout兩個屬性值會影響決定連接配接是否逾時，如果隊列過長後面的請求就會出現逾時，這樣請求同樣也無法被正确的處理，是以在設定該值時，需要以伺服器通路的峰值或平均值來衡量，但實際測試過程中可以通過配置該值來測試性能的表現。

下期分享APR配置，敬請關注！