Socket引數選項：
1、TCP_NODELAY：表示立即傳送資料。
2、SO_RESUSEADDR：表示允許重用Socket所繫結的本地地址
3、SO_TIMEOUT：表示接受資料時的超時時間。
4、SO_LINGER：表示當執行close()；方法時候，是否理解關閉底層的socket。（Reset報文）
setSoLinger（true, 0): 執行該方法，那麼執行Socket的close方法，該方法也會立即返回，但底層的Socket也會立即關閉，所有未傳送完的剩餘資料被丟棄
setSoLinger(true, 3600): 那麼執行Socket的close方法，該方法不會立即返回，而進入阻塞狀態，同時，底層的Socket也會嘗試傳送剩餘的資料，只有滿足下面的兩個條件之一，close方法才會返回：
（1）：底層的Socket已經發送完所有的剩餘資料
（2）： 儘管底層的Socket還沒有傳送完所有的剩餘資料，但已經阻塞了3600秒，close()方法的阻塞時間超過3600秒，也會返回，剩餘未傳送的資料被丟棄。
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉；net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉。
5、SO_SNFBUF：表示傳送資料的緩衝大小
6、SO_RCVBUF：表示接受資料的緩衝區的大小
7、SO_KEEPALIVE：表示長時間處於空閒狀態的SOCEKT，是否自動把他/她關閉
8、OOBINLINE：表示是否支援傳送一個位元組的TCP緊急資料
預設引數
注： Connector 通常在%HOME_TOMCAT%/conf/servser.xml 檔案內
# 正常引數
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
配置引數除錯
# 最佳化引數
<Connector port="8080"
protocol="HTTP/1.1"
maxThreads="1000"
minSpareThreads="100"
acceptCount="1000"
maxConnections="1000"
maxHttpHeaderSize="8192"
tcpNoDelay="true"
compression="on"
compressionMinSize="2048"
disableUploadTimeout="true"
redirectPort="8443"
enableLookups="false"
URIEncoding="UTF-8" />
引數詳解
1）port
注：代表Tomcat埠號，預設8080。
2）protocol
注：協議型別，可選型別有4種，BIO（阻塞型IO），NIO，NIO2和APR。
# BIO
BIO(Blocking I/O) 阻塞式I/O操作，傳統的Java I/O操作(即java.io包及其子包)。Tomcat在預設情況下，是以bio模式執行的，bio模式是三種執行模式中效能最低的一種。BIO配置採用預設即可。
BIO更適合處理簡單流程，如程式處理較快可以立即返回結果。簡單專案及應用可以採用BIO。
# NIO
NIO(New I/O)是Java SE 1.4及後續版本提供的一種新的I/O操作方式(即java.nio包及其子包)。Java nio是一個基於緩衝區、非阻塞I/O操作的Java API它擁有比傳統I/O操作(bio)更好的併發執行效能。
NIO更適合後臺需要耗時完成請求的操作，如程式接到了請求後需要比較耗時的處理這已請求，所以無法立即返回結果，這樣如果採用BIO就會佔用一個連線，而使用NIO後就可以將此連線轉讓給其他請求，直至程式處理完成返回為止。
# APR
APR(Apache Portable Runtime/Apache可移植執行時)，是Apache HTTP伺服器的支援庫。你可以簡單地理解為:Tomcat將以JNI的形式呼叫 Apache HTTP伺服器的核心動態連結庫來處理檔案讀取或網路傳輸操作，從而大大地提高 Tomcat對靜態檔案的處理效能。
APR可以大大提升Tomcat對靜態檔案的處理效能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理效能。
# 修改方式
//BIO
//NIO
protocol="org.apache.coyote.http11.Http11NioProtocol"
//NIO2
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
//APR
protocol="org.apache.coyote.http11.Http11AprProtocol"
3）maxThreads (執行緒池的大小預設200)
注：聯結器建立處理請求執行緒的最大數目，處理同事請求的最大數目，預設值為200。
如果一個執行器與此聯結器關聯，則忽略此屬性，因為該屬性將被忽略，所以該聯結器將使用執行器而不是一個內部執行緒池來執行任務。maxThreads是一個重要的配置屬性，maxThreads配置的合理直接影響了Tomcat的相關效能。maxThreads並不是配置的越大越好，事實上你即使配置成999999也是沒有用的，因為這個最大值是受作業系統及相關硬體所制約的，並且最大值並不一定是最優值，所以我們追尋的應該是最優值而不是最大值。
QPS（Query Per Second）：每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。我們常常使用 QPS值來衡量一個伺服器的效能。
QPS = 併發數 / 平均響應時間
併發數 = QPS * 平均響應時間
一個系統吞吐量通常由QPS、併發數兩個因素決定，每套系統的這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導致系統性能下降。所謂吞吐量這裡可以理解為每秒能處理請求的次數。
所以選擇一個合理的 maxThreads值，其實並不是那麼容易的事。因為過多的執行緒只會造成，更多的記憶體開銷，更多的CPU開銷，但是對提升QPS確毫無幫助；找到最佳執行緒數後透過簡單的設定，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出。
# 獲取最佳maxThreads的最佳值
（1）透過線上系統不斷使用和使用者的不斷增長來進行效能測試，觀察QPS，響應時間，這種方式會在爆發式增長時系統崩潰，如雙12等。
（2）根據公式計算，伺服器端最佳執行緒數量=((執行緒等待時間+執行緒cpu時間)/執行緒cpu時間) * cpu數量，這種方式有時會被誤導，因為某些系統處理環節可能會耗時比較長，從而影響公式的結果。
（3）單、多使用者壓力測試，檢視CPU的消耗，然後直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳執行緒數量，這種方式理想場景比較適用，實際情況會比這個複雜的多。
（4）根據系統的自身情況調整，如硬體限制，系統限制，程式處理能力限制等。
（5）定期修改為不同的 maxThreads值，看伺服器響應結果及使用者反應。
# QPS和執行緒數的關係
（1）在最佳執行緒數量之前，QPS和執行緒是互相遞增的關係，執行緒數量到了最佳執行緒之後，QPS持平，不在上升，甚至略有下降，同時相應時間持續上升。
（2）同一個系統而言，支援的執行緒數越多（最佳執行緒數越多而不是配置的執行緒數越多），QPS越高。
# QPS和響應時間的關係
（1）對於一般的web系統，響應時間一般有CPU執行時間+IO等待時間組成。
（2）CPU的執行時間減少，對QPS有實質的提升，IO時間的減少，對QPS提升不明顯。如果要想明顯提升QPS，最佳化系統的時候要著重最佳化CPU消耗大戶。
4）minSpareThreads
注：執行緒的最小執行數目，這些始終保持執行。如果未指定，預設值為10。
5）acceptCount （預設為100,ServerSocket.accept佇列，backlog:半佇列的大小）
注：最大佇列長度。一般與maxThreads相同，預設為100。
當所有可能的請求處理執行緒都在使用時傳入連線請求的最大佇列長度。如果未指定，預設值為100。一般是設定的跟 maxThreads一樣或一半，此值設定的過大會導致排隊的請求超時而未被處理。所以這個值應該是主要根據應用的訪問峰值與平均值來權衡配置。
6）maxConnections （NIO與NIO2的預設值為10000，accept的Socket的大小）
注：在任何給定的時間內，伺服器將接受和處理的最大連線數。當這個數字已經達到時，伺服器將接受但不處理，等待進一步連線。NIO與NIO2的預設值為10000，APR預設值為8192。
7）connectionTimeout （設定到Socket.setSoTimeout(connectionTimeout )）
注：當請求已經被接受，但未被處理，也就是等待中的超時時間。單位為毫秒，預設值為60000。通常情況下設定為30000。
8）maxHttpHeaderSize
注：請求和響應的HTTP頭的最大大小，以位元組為單位指定。如果沒有指定，這個屬性被設定為8192（8 KB）。
9）tcpNoDelay
注：如果為true，伺服器socket會設定TCP_NO_DELAY選項，在大多數情況下可以提高效能。預設情況下設為true。
10）compression
注：是否啟用gzip壓縮，預設為關閉狀態。這個引數的可接受值為“off”（不使用壓縮），“on”（壓縮文字資料），“force”（在所有的情況下強制壓縮）。
11）compressionMinSize
注：如果compression="on"，則啟用此項。被壓縮前資料的最小值，也就是超過這個值後才被壓縮。如果沒有指定，這個屬性預設為“2048”（2K），單位為byte。
12）disableUploadTimeout
注：這個標誌允許servlet Container在一個servlet執行的時候，使用一個不同的，更長的連線超時。最終的結果是給servlet更長的時間以便完成其執行，或者在資料上傳的時候更長的超時時間。如果沒有指定，設為false。
13）enableLookups
注：關閉DNS反向查詢。
14）URIEncoding
注：URL編碼字符集。
Socket引數選項：
1、TCP_NODELAY：表示立即傳送資料。
2、SO_RESUSEADDR：表示允許重用Socket所繫結的本地地址
3、SO_TIMEOUT：表示接受資料時的超時時間。
4、SO_LINGER：表示當執行close()；方法時候，是否理解關閉底層的socket。（Reset報文）
setSoLinger（true, 0): 執行該方法，那麼執行Socket的close方法，該方法也會立即返回，但底層的Socket也會立即關閉，所有未傳送完的剩餘資料被丟棄
setSoLinger(true, 3600): 那麼執行Socket的close方法，該方法不會立即返回，而進入阻塞狀態，同時，底層的Socket也會嘗試傳送剩餘的資料，只有滿足下面的兩個條件之一，close方法才會返回：
（1）：底層的Socket已經發送完所有的剩餘資料
（2）： 儘管底層的Socket還沒有傳送完所有的剩餘資料，但已經阻塞了3600秒，close()方法的阻塞時間超過3600秒，也會返回，剩餘未傳送的資料被丟棄。
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連線，預設為0，表示關閉；net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉。
5、SO_SNFBUF：表示傳送資料的緩衝大小
6、SO_RCVBUF：表示接受資料的緩衝區的大小
7、SO_KEEPALIVE：表示長時間處於空閒狀態的SOCEKT，是否自動把他/她關閉
8、OOBINLINE：表示是否支援傳送一個位元組的TCP緊急資料
預設引數
注： Connector 通常在%HOME_TOMCAT%/conf/servser.xml 檔案內
# 正常引數
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
配置引數除錯
# 最佳化引數
<Connector port="8080"
protocol="HTTP/1.1"
maxThreads="1000"
minSpareThreads="100"
acceptCount="1000"
maxConnections="1000"
connectionTimeout="20000"
maxHttpHeaderSize="8192"
tcpNoDelay="true"
compression="on"
compressionMinSize="2048"
disableUploadTimeout="true"
redirectPort="8443"
enableLookups="false"
URIEncoding="UTF-8" />
引數詳解
1）port
注：代表Tomcat埠號，預設8080。
2）protocol
注：協議型別，可選型別有4種，BIO（阻塞型IO），NIO，NIO2和APR。
# BIO
BIO(Blocking I/O) 阻塞式I/O操作，傳統的Java I/O操作(即java.io包及其子包)。Tomcat在預設情況下，是以bio模式執行的，bio模式是三種執行模式中效能最低的一種。BIO配置採用預設即可。
BIO更適合處理簡單流程，如程式處理較快可以立即返回結果。簡單專案及應用可以採用BIO。
# NIO
NIO(New I/O)是Java SE 1.4及後續版本提供的一種新的I/O操作方式(即java.nio包及其子包)。Java nio是一個基於緩衝區、非阻塞I/O操作的Java API它擁有比傳統I/O操作(bio)更好的併發執行效能。
NIO更適合後臺需要耗時完成請求的操作，如程式接到了請求後需要比較耗時的處理這已請求，所以無法立即返回結果，這樣如果採用BIO就會佔用一個連線，而使用NIO後就可以將此連線轉讓給其他請求，直至程式處理完成返回為止。
# APR
APR(Apache Portable Runtime/Apache可移植執行時)，是Apache HTTP伺服器的支援庫。你可以簡單地理解為:Tomcat將以JNI的形式呼叫 Apache HTTP伺服器的核心動態連結庫來處理檔案讀取或網路傳輸操作，從而大大地提高 Tomcat對靜態檔案的處理效能。
APR可以大大提升Tomcat對靜態檔案的處理效能，同時如果你使用了HTTPS方式傳輸的話，也可以提升SSL的處理效能。
# 修改方式
//BIO
protocol="HTTP/1.1"
//NIO
protocol="org.apache.coyote.http11.Http11NioProtocol"
//NIO2
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
//APR
protocol="org.apache.coyote.http11.Http11AprProtocol"
3）maxThreads (執行緒池的大小預設200)
注：聯結器建立處理請求執行緒的最大數目，處理同事請求的最大數目，預設值為200。
如果一個執行器與此聯結器關聯，則忽略此屬性，因為該屬性將被忽略，所以該聯結器將使用執行器而不是一個內部執行緒池來執行任務。maxThreads是一個重要的配置屬性，maxThreads配置的合理直接影響了Tomcat的相關效能。maxThreads並不是配置的越大越好，事實上你即使配置成999999也是沒有用的，因為這個最大值是受作業系統及相關硬體所制約的，並且最大值並不一定是最優值，所以我們追尋的應該是最優值而不是最大值。
QPS（Query Per Second）：每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。我們常常使用 QPS值來衡量一個伺服器的效能。
QPS = 併發數 / 平均響應時間
併發數 = QPS * 平均響應時間
一個系統吞吐量通常由QPS、併發數兩個因素決定，每套系統的這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、記憶體等等其它消耗導致系統性能下降。所謂吞吐量這裡可以理解為每秒能處理請求的次數。
所以選擇一個合理的 maxThreads值，其實並不是那麼容易的事。因為過多的執行緒只會造成，更多的記憶體開銷，更多的CPU開銷，但是對提升QPS確毫無幫助；找到最佳執行緒數後透過簡單的設定，可以讓web系統更加穩定，得到最高，最穩定的QPS輸出。
# 獲取最佳maxThreads的最佳值
（1）透過線上系統不斷使用和使用者的不斷增長來進行效能測試，觀察QPS，響應時間，這種方式會在爆發式增長時系統崩潰，如雙12等。
（2）根據公式計算，伺服器端最佳執行緒數量=((執行緒等待時間+執行緒cpu時間)/執行緒cpu時間) * cpu數量，這種方式有時會被誤導，因為某些系統處理環節可能會耗時比較長，從而影響公式的結果。
（3）單、多使用者壓力測試，檢視CPU的消耗，然後直接乘以百分比，再進行壓測，一般這個值的附近應該就是最佳執行緒數量，這種方式理想場景比較適用，實際情況會比這個複雜的多。
（4）根據系統的自身情況調整，如硬體限制，系統限制，程式處理能力限制等。
（5）定期修改為不同的 maxThreads值，看伺服器響應結果及使用者反應。
# QPS和執行緒數的關係
（1）在最佳執行緒數量之前，QPS和執行緒是互相遞增的關係，執行緒數量到了最佳執行緒之後，QPS持平，不在上升，甚至略有下降，同時相應時間持續上升。
（2）同一個系統而言，支援的執行緒數越多（最佳執行緒數越多而不是配置的執行緒數越多），QPS越高。
# QPS和響應時間的關係
（1）對於一般的web系統，響應時間一般有CPU執行時間+IO等待時間組成。
（2）CPU的執行時間減少，對QPS有實質的提升，IO時間的減少，對QPS提升不明顯。如果要想明顯提升QPS，最佳化系統的時候要著重最佳化CPU消耗大戶。
4）minSpareThreads
注：執行緒的最小執行數目，這些始終保持執行。如果未指定，預設值為10。
5）acceptCount （預設為100,ServerSocket.accept佇列，backlog:半佇列的大小）
注：最大佇列長度。一般與maxThreads相同，預設為100。
當所有可能的請求處理執行緒都在使用時傳入連線請求的最大佇列長度。如果未指定，預設值為100。一般是設定的跟 maxThreads一樣或一半，此值設定的過大會導致排隊的請求超時而未被處理。所以這個值應該是主要根據應用的訪問峰值與平均值來權衡配置。
6）maxConnections （NIO與NIO2的預設值為10000，accept的Socket的大小）
注：在任何給定的時間內，伺服器將接受和處理的最大連線數。當這個數字已經達到時，伺服器將接受但不處理，等待進一步連線。NIO與NIO2的預設值為10000，APR預設值為8192。
7）connectionTimeout （設定到Socket.setSoTimeout(connectionTimeout )）
注：當請求已經被接受，但未被處理，也就是等待中的超時時間。單位為毫秒，預設值為60000。通常情況下設定為30000。
8）maxHttpHeaderSize
注：請求和響應的HTTP頭的最大大小，以位元組為單位指定。如果沒有指定，這個屬性被設定為8192（8 KB）。
9）tcpNoDelay
注：如果為true，伺服器socket會設定TCP_NO_DELAY選項，在大多數情況下可以提高效能。預設情況下設為true。
10）compression
注：是否啟用gzip壓縮，預設為關閉狀態。這個引數的可接受值為“off”（不使用壓縮），“on”（壓縮文字資料），“force”（在所有的情況下強制壓縮）。
11）compressionMinSize
注：如果compression="on"，則啟用此項。被壓縮前資料的最小值，也就是超過這個值後才被壓縮。如果沒有指定，這個屬性預設為“2048”（2K），單位為byte。
12）disableUploadTimeout
注：這個標誌允許servlet Container在一個servlet執行的時候，使用一個不同的，更長的連線超時。最終的結果是給servlet更長的時間以便完成其執行，或者在資料上傳的時候更長的超時時間。如果沒有指定，設為false。
13）enableLookups
注：關閉DNS反向查詢。
14）URIEncoding
注：URL編碼字符集。