tomcat

一  Tomcat調優

      本節主要參考文章：http://www.javashuo.com/article/p-hhizcbyu-ge.html

      GZIP壓縮參考文章：http://www.javashuo.com/article/p-obbaupdv-p.html

      1.  JVM調優

           注：JDK調優在Tomcat裏調而不須要在JDK裏調優，Tomcat啓動的是JVM的一個實

                  例，而JDK自己沒有提供咱們調優的地方。

     文件： \tomcat server folder\bin\catalina.sh

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8
-server -Xms1024m -Xmx1024m
-XX:NewSize=512m -XX:MaxNewSize=512m -XXermSize=512m
-XX:MaxPermSize=512m -XX:+DisableExplicitGC"

      2.  設置監聽器解決JRE和PermGen的內存泄漏

           性能表現不佳的另外一個主要緣由是內存泄漏，正如我以前說過：始終使用最新的

           tomcat服務器以得到更好的性能和可伸縮性。如今，這句話變成真的。若是咱們使用

           最新的tomcat版本6.0.26及以上就能夠解決這個錯誤，由於它包含了一個監聽器來處

           理JRE和PermGen的內存泄漏。設置使用的監聽器是server.xml中的：

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

      3.  鏈接池設置

           線程池指定Web請求負載的數量，所以，爲得到更好的性能這部分應當心處理。能夠

           經過調整鏈接器屬性「maxThreads」完成設置。maxThreads的值應該根據流量的大小，

           若是值太低，將有沒有足夠的線程來處理全部的請求，請求將進入等待狀態，只有當

           一個的處理線程釋放後才被處理；若是設置的太大，Tomcat的啓動將花費更多時間。

           所以它取決於咱們給maxThreads設置一個正確的值。 

<Connector port="8080" address="localhost"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8181" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />

           在上述配置中，maxThreads值設定爲「250」，這指定能夠由服務器處理的併發請求的

           最大數量。若是沒有指定，這個屬性的默認值爲「200」。任何多出的併發請求將收到

           「拒絕鏈接」的錯誤提示，直到另外一個處理請求進程被釋放。錯誤看起來以下，

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

           若是應用提示上述錯誤，務必檢查上述錯誤是不是因爲單個請求花費太長時間形成的，

           這個問題的緣由是這樣的，有時候若是數據庫鏈接不釋放的話，進程將不會處理其它請

           求。

           注意：若是請求的數量超過了「750」，這將不是意味着將maxThreads屬性值設置爲「750」，

                     它意外着最好使用「Tomcat集羣」的多個實例。也就是說，若是有「1000」請求，兩個

                     Tomcat實例設置「maxThreads= 500」，而不在單Tomcat實例的狀況下設置

                     maxThreads=1000

      4.  配置壓縮

         （1）爲何要壓縮？

                          HTTP壓縮能夠大大提升瀏覽網站的速度，它的原理是，在客戶端請求服務器對應資

                   源後，從服務器端將資源文件壓縮，再輸出到客戶端，由客戶端的瀏覽器負責解壓縮並

                   瀏覽（可見，壓縮的是響應）。即：經過減少HTTP響應大小來減小響應時間。相對於普

                   通的瀏覽過程HTML、CSS、Javascript、Text ，它能夠節省40%左右的流量。更爲重要

                   的是，它能夠對動態生成的，包括CGI、PHP , JSP , ASP , Servlet、SHTML等輸出的網

                   頁也能進行壓縮，壓縮效率也很高。而GZIP自己就是一種網絡流壓縮算法，並且應用相

                   當普遍Tomcat有一個經過在server.xml配置文件中設置壓縮的選項。壓縮能夠在

                   Connector像以下設置中完成。

         （2）GZIP壓縮介紹：

                 （a）HTTP 協議支持GZIP 壓縮機制，也稱協議壓縮。 HTTP GZIP壓縮是由WEB服務器

                          和瀏覽器共同遵照的協議，也就是說WEB服務器和瀏覽器都必須遵照。目前主流的

                          服務器和瀏覽器都支持GZIP壓縮技術。包括 Chrome、IE、FireFox、Opera 等；服

                          務器有 tomcat、Apache 和 IIS 等。

                 （b）GZIP 主要用來壓縮html,css,javascript,等靜態文本文件，也支持對動態生成的，包

                       括CGI、PHP , JSP , ASP , Servlet,SHTML等輸出的網頁也能進行壓縮。

                 （c）GZIP 壓縮的比率一般在3~10 倍之間，這樣能夠大大節省服務器的網絡帶寬，大大

                          提高瀏覽器的瀏覽速度。

                 （d）GZIP 是一種數據壓縮格式，默認且目前僅使用deflate算法壓縮data部分；deflate是

                          一種壓縮算法,是huffman編碼的一種增強。

                 （e）協議壓縮就是依據HTTP協議進行壓縮，不須要程序員進行壓縮，解壓編碼，而是把

                          壓縮過程交給WEB服務器，將解壓過程交給客戶端。 若是客戶端爲支持GZIP壓縮的

                          瀏覽器，那麼解壓過程也不須要程序員參與，瀏覽器會按照必定的規則自動進行解壓

                          縮；若是客戶端爲HttpClient ，那麼就須要手動進行GZIP解碼了。

                 （f）壓縮過程：客戶端發送http請求，若是請求頭header中攜帶

                          Accept-Encoding: gzip,deflate (如今的瀏覽器通常默認都是這樣)，那麼瀏覽器的意思

                         是:服務器須要進行GZIP壓縮,再看響應內容的類型是否知足服務器配置的須要壓縮的

                         類型，若是符合，那麼WEB服務器在傳輸響應內容以前，會對響應內容進行壓縮，並

                         在響應頭中添加Content-Encoding gzip；若是不符合，那麼將不壓縮，直接返回。

                 （g） 解壓過程：（瀏覽器）客戶端接收到響應，若是響應頭中包含

                           Content-Encoding GZIP，那麼瀏覽器會自動將響應內容進行GZIP解壓縮，而後再呈

                           如今頁面上。若是不包含，那麼將直接呈如今頁面上。

                 （h）GZIP的缺點。相對於沒有進行GZIP的工程來講，使用GZIP要增長服務器壓縮的壓力

                        （cpu消耗）、客戶端解壓縮的壓力，故而對服務器的配置需求更高。另外壓縮也要耗

                          費時間，想佔用更小的空間，獲得高壓縮比率，確定要犧牲較長的時間；反之，若是

                          時間較爲寶貴，要求快速，那麼所得的壓縮比率必定較小，固然會佔用更大的空間了

                        （壓縮比率=原內容大小/壓縮後大小，壓縮比率越大，則代表壓縮後佔用空間的壓縮

                          包越小），這就是物理空間與時間的矛盾。

         （3）筆者的案例

                  最近作了個項目，遇到這麼一個問題：服務器返回給客戶端的json數據量太大（大概

                  65M），在客戶端加載了1分多鐘才渲染完畢(固然這加載時間也和本地的下行帶寬有關)，

                  費時耗流量，用戶體驗極其很差。後來網上搜優化的方法，就是Http壓縮         

         （4）Tomcat中配置的方法

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8181" compression="500"
compressableMimeType="text/html,text/xml,text/plain,application/octet-stream" />

                 在上面的配置中，當文件的大小大於等於500bytes時纔會壓縮。若是當文件達到了大小可是

                 卻沒有被壓縮，那麼設置屬性compression="on"。不然Tomcat默認設置是「off」。

      5.  數據庫調優

           Tomcat性能在等待數據庫查詢被執行期間會下降。現在大多數應用程序都是使用可能包含「命名

           查詢」的關係型數據庫。若是是那樣的話，Tomcat會在啓動時默認加載命名查詢，這個可能會提

           升性能。另外一件重要事是確保全部數據庫鏈接正確地關閉。給數據庫鏈接池設置正確值也是十

           分重要的。我所說的值是指Resource要素的最大空閒數（maxIdle），最大鏈接數

         （maxActive）,最大創建鏈接等待時間（maxWait）屬性的值。由於配置依賴與應用要求，我也

           不能在本文指定正確的值。你能夠經過調用數據庫性能測試來找到正確的值。

      6.  Tomcat的原生庫基於Apache可移植運行時（Apache Portable Runtime簡稱APR），給程

         序員提供了超強的擴展性和性能，在產品運做中幫助融合原生的服務器技術以展示最佳的性能。

         想知道安裝說明的朋友請參考Tomcat Native Library – (APR) Installation。

      7.  其它選項

          開啓瀏覽器的緩存，這樣讀取存放在webapps文件夾裏的靜態內容會更快，大大推進總體性

          能。每當開機時，Tomcat服務器應當自動地重啓。通常狀況下HTTPS請求會比HTTP請求慢。

          若是你想要更好的安全性，即便慢一點咱們仍是要選擇HTTPS。

Tomcat性能在等待數據庫查詢被執行期間會下降。現在大多數應用程序都是使用可能包含「命名查詢」的關係型數據庫。若是是那樣的話，Tomcat會在啓動時默認加載命名查詢，這個可能會提高性能。另外一件重要事是確保全部數據庫鏈接正確地關閉。給數據庫鏈接池設置正確值也是十分重要的。我所說的值是指Resource要素的最大空閒數（maxIdle），最大鏈接數（maxActive）,最大創建鏈接等待時間（maxWait）屬性的值。由於配置依賴與應用要求，我也不能在本文指定正確的值。你能夠經過調用數據庫性能測試來找到正確的值。