jetty安裝、配置、優化

)Jetty：

做用：Jetty 是一個開源的servlet容器，它爲基於Java的web內容，例如JSP和servlet提供運行環境。

特性：易用性，可擴展性，易嵌入性

2) Jetty安裝：

tar zxf jetty.tar.gz -C /usr/local/jetty/ #解壓

Java -jar stat.jar #啓動jetty

export JETTY_HOME=/usr/java/jetty #將Jetty路徑添加到環境變量

3) Jetty配置：

etc:該路徑用於存放Jetty的配置文件

examples:該路徑用於存放Jetty的示例。

legal:該路徑用於存放該項目的Lisence信息。

lib:該路徑用於存放運行Jetty必需的靜態庫文件。

modules:該路徑用於存放Jetty的模塊，包括API文檔。

patches:包含一些補丁說明。

pom.xm1:是Jetty的build文件，該文件不是Ant的build文件，而是mavaen2的build文件。

project-site:包含Jetty的網站的必需的樣式文件。

readme.txt:包含最基本的使用信息。

start.jar:啓動Jetty的啓動文件。

version.txt:Jetty版本更新日誌的簡單版本。

webapps: 該路徑用於存放自動部署的Web 應用，只要將用戶的Web應用複製到該路徑下，Web應用將自動部署

webapps-plus: 存放一些用於演示Jetty 擴展屬性的Web 應用，該路徑下的Web應用也可自動部署。

4) Jetty與Tomcat 

 相同點：

Tomcat和Jetty都是一種Servlet引擎，他們都支持標準的servlet規範和JavaEE的規範。

 不一樣點：

1.架構比較

Jetty的架構比Tomcat的更爲簡單

Jetty的架構是基於Handler來實現的，主要的擴展功能均可以用Handler來實現，擴展簡單。

Tomcat的架構是基於容器設計的，進行擴展是須要了解Tomcat的總體設計結構，不易擴展。

2. 性能比較

Jetty和Tomcat性能方面差別不大

Jetty能夠同時處理大量鏈接並且能夠長時間保持鏈接，適合於web聊天應用等等。

Jetty的架構簡單，所以做爲服務器，Jetty能夠按需加載組件，減小不須要的組件，減小了服務器內存開銷，從而提升服務器性能。

Jetty默認採用NIO結束在處理I/O請求上更佔優點，在處理靜態資源時，性能較高

Tomcat適合處理少數很是繁忙的連接，也就是說連接生命週期短的話，Tomcat的整體性能更高。

Tomcat默認採用BIO處理I/O請求，在處理靜態資源時，性能較差。

3.其它比較

Jetty的應用更加快速，修改簡單，對新的Servlet規範的支持較好。

Tomcat目前應用比較普遍，對JavaEE和Servlet的支持更加全面，不少特性會直接集成進來。

5) Jetty優化：

1、通常調優的基本過程

1.明瞭須要調優的系統架構

2.設定性能調優的目標

3.明瞭目標當前的性能狀況

4.找出目前的性能瓶頸的所在

5.解決引發性能瓶頸的根本問題

6.重複以上過程直到達到設定目標性能爲止

2、性能指標：

崩潰點：同時多少併發的時候，服務器Down掉？

吞吐量:多少人一塊兒來，都沒問題？

併發數:每秒能處理多少人？

響應時間：每人須要等待的時間多長？

3、調優勢：

1.硬件配置優化：

虛擬機

物理機

CPU 

內存 

 

二、系統優化（Linux)

已經根據門戶的方式去優化。

 

3.JVM參數優化：

-Xms：設置jvm內存的初始大小

-Xmx：設置jvm內存的最大值

-Xmn：設置新域的大小（這個彷佛只對 jdk1.4來講是有效的，後來就廢棄了）

-Xss：設置每一個線程的堆棧大小(也就是說,在相同物理內存下，減少這個值能生成更多的線程)

-XX：NewRatio :設置新域與舊域之比，如-XX：NewRatio = 4就表示新域與舊域之比爲1：4

-XX:NewSize：設置新域的初始值

-XX:MaxNewSize ：設置新域的最大值

-XX:PermSize：設置永久域的初始值

-XX:MaxPermSize：設置永久域的最大值

-XX:SurvivorRatio=n:設置新域中Eden區與兩個Survivor區的比值。（Eden區主要是用來存放新生的對象，而兩個 Survivor區則用來存放每次垃圾回收後存活下來的對象）

監控內存 CPU

常見的錯誤 ：

java.lang.OutOfMemoryError相信不少開發人員都用到過，這個主要就是JVM參數沒有配好引發的，可是這種錯誤又分兩種：java.lang.OutOfMemoryError: Java heap space和

java.lang.OutOfMemoryError: PermGen space，其中前者是有關堆內存的內存溢出，能夠同過配置-Xms和-Xmx參數來設置，然後者是有關永久域的內存溢出，能夠經過配置-XX:MaxPermSize來設置。

 

4.容器優化：

a.線程池

 

線程池線程資源大小肯定了服務器的服務能力

默認大小不必定能知足生產環境

線程分配方式決定了服務器的資源利用效率

固定線程數處理多任務,表明：JDK的ThreadPoolExecutor

以最大線程數爲限處理多任務，表明：Jetty自帶QueuedThreadPool

Work-stealing 分配，Jetty目前沒有這個實現 Jetty中配置實例：

 

 

maxThreads：表示最多同時處理的鏈接數。應該將線程數（最大線程數）設置比最大預期負載（同時併發的點擊）多25%（經驗規則）(低配置用戶可經過下降maxThreads並同時增大

acceptCount值來保證系統的穩定)。

acceptCount：當同時鏈接的人數達到maxThreads時，還能夠接收排隊的鏈接。

minSpareThread：指「啓動之後，老是保持該數量的線程空閒等待」；設置比預期負載多25%。

maxSpareThread：指「若是超過了minSpareThread，而後老是保持該數量的線程空閒等待」；設置比預期負載多25%。

其中主要修改兩個參數maxThreads和acceptCount值。增長maxThreads，減小acceptCount值有利縮短系統的響應時間。可是maxThreads和acceptCount的總和最高值不能超過6000，並且

maxThreads過大會增長CPU和內存消耗，故低配置用戶可經過下降maxThreads並同時增大acceptCount值來保證系統的穩定。

connectionTimeout：鏈接超時，最大超時時間，當響應速度慢的時候，經過調整該參數，來平衡正確率和服務器資源的回收。

 

b.Connectors

選擇Connector時，須要考慮應用自身的特色，例如股票、聊天室.

TCP 鏈接數 Keep-Alive Java BIO Connectors SocketConnector (HTTP) 

Ajp13SocketConnector (AJP) SslSocketConnector(SSL)

Java NIO Connectors electChannelConnector(HTTP) SslSelectChannelConnector(SSL)

 

Acceptors 表示同時在監聽read事件的線程數

默認值是 1 典型值範圍 1~(處理器內核數+1) 

對於NIO 來講，設置爲(處理器內核數+1)比較合適

maxIdleTime 表示鏈接最大空閒時間 默認值是 200000，通常這個值都太大了

典型值 3000 左右足夠 

對AJP來講通常設置爲-1，表示鏈接須要一直保持

 

LowResourcesMaxIdleTime 表示線程資源稀少時的maxIdleTime 默認值是 -1，表示沒有設置 

通常設置值應該<=maxIdleTime

lowResourcesConnections 只有NIO纔有這個設置，表示鏈接空閒時的鏈接數，大於這個數將被shutdown 

默認值是 0,表示該設置沒有生效 每一個acceptor的鏈接數=(lowResourcesConnections+acceptors-1)/acceptors

 

AcceptQueueSize 鏈接被 accept 前容許等待的鏈接數即Socket的Backlog ，默認 50

SoLingerTime 具備指定逗留時間（以毫秒爲單位) 即socket的setSoLinger，默認關閉

ResolveNames 是否反查 getRemoteHost() 默認false

 

c.JVM

Jetty性能調優勢-JVM

JVM參數調整主要涉及兩個方面 

堆/棧內存大小調整 

Xmx/xms 最大/最小堆大小 

xmn 新生代大小 

-XX:MaxPermSize 持久代堆大小 

垃圾分配回收算法考慮暫停時間、吞吐量選擇不一樣算法 

串行/並行/併發收集

 

d.Content Cache

動態內容不會被cache 靜態內容纔會被cache

maxCacheSize 256,000,000

maxCachedFileSize 200,000,000

maxCachedFiles ?2,048

useFileMappedBuffer ?true

能夠經過etc/webdefault.xml配置

 

e.冗餘組件去除

去除多餘的Connector 去除不須要的構建Handler 例如SessionHandler,ServletHandler

關閉沒必要要的服務 例如 jmx-console。(JBoss)

 

5.代碼優化：

在高峯期，減去日誌記錄的操做，或者把日誌暫時先緩存起來，使用異步處理的方式。

減小一些數據庫操做。

減小NC 身份證等匹配方式。

 

6.數據庫優化：

索引

視圖

 

7.其餘：

壓縮css,js,圖片

使用瀏覽器緩存

CDN加速

分佈式緩存服務器

集羣、負載均衡

 

三.調優策略：

a.關鍵點，找到瓶頸,給瓶頸分配更多的資源，或者減輕其工做量。

 

4、調優原則

a.每臺服務器，所能承載的參數，都會有差別，尤爲是內存 CPU的配置不一致。

b.每種服務所需的計算資源各不相同，要根據服務的偏向不一樣，而去把最好的資源，分配到最須要的地方

c.性能優化，是永恆的話題，沒有永久最優解，只能查出目前最優解,是一個不斷優化的過程。

 

5、調優技巧

1.粗狂的掃點與詳細的指標相結合，儘可能讓驗證調優的過程更敏捷,讓主要的指標穩定下來，在肯定指標前，再使用詳細的方式去測出各類指標。

2.分輪測試，在測試結果中，找出各個參數的規律。爲調優提供指導數據。

3.在程序增長計數器，驗證LR的請求次數。

4.在程序每一個步驟，增長多一些時間，檢查下，究竟是卡在哪一個步驟，尤爲是操做數據庫先後。

)Jetty：

做用：Jetty 是一個開源的servlet容器，它爲基於Java的web內容，例如JSP和servlet提供運行環境。

特性：易用性，可擴展性，易嵌入性

2) Jetty安裝：

tar zxf jetty.tar.gz -C /usr/local/jetty/ #解壓

Java -jar stat.jar #啓動jetty

export JETTY_HOME=/usr/java/jetty #將Jetty路徑添加到環境變量

3) Jetty配置：

etc:該路徑用於存放Jetty的配置文件

examples:該路徑用於存放Jetty的示例。

legal:該路徑用於存放該項目的Lisence信息。

lib:該路徑用於存放運行Jetty必需的靜態庫文件。

modules:該路徑用於存放Jetty的模塊，包括API文檔。

patches:包含一些補丁說明。

pom.xm1:是Jetty的build文件，該文件不是Ant的build文件，而是mavaen2的build文件。

project-site:包含Jetty的網站的必需的樣式文件。

readme.txt:包含最基本的使用信息。

start.jar:啓動Jetty的啓動文件。

version.txt:Jetty版本更新日誌的簡單版本。

webapps: 該路徑用於存放自動部署的Web 應用，只要將用戶的Web應用複製到該路徑下，Web應用將自動部署

webapps-plus: 存放一些用於演示Jetty 擴展屬性的Web 應用，該路徑下的Web應用也可自動部署。

4) Jetty與Tomcat 

 相同點：

Tomcat和Jetty都是一種Servlet引擎，他們都支持標準的servlet規範和JavaEE的規範。

 不一樣點：

1.架構比較

Jetty的架構比Tomcat的更爲簡單

Jetty的架構是基於Handler來實現的，主要的擴展功能均可以用Handler來實現，擴展簡單。

Tomcat的架構是基於容器設計的，進行擴展是須要了解Tomcat的總體設計結構，不易擴展。

2. 性能比較

Jetty和Tomcat性能方面差別不大

Jetty能夠同時處理大量鏈接並且能夠長時間保持鏈接，適合於web聊天應用等等。

Jetty的架構簡單，所以做爲服務器，Jetty能夠按需加載組件，減小不須要的組件，減小了服務器內存開銷，從而提升服務器性能。

Jetty默認採用NIO結束在處理I/O請求上更佔優點，在處理靜態資源時，性能較高

Tomcat適合處理少數很是繁忙的連接，也就是說連接生命週期短的話，Tomcat的整體性能更高。

Tomcat默認採用BIO處理I/O請求，在處理靜態資源時，性能較差。

3.其它比較

Jetty的應用更加快速，修改簡單，對新的Servlet規範的支持較好。

Tomcat目前應用比較普遍，對JavaEE和Servlet的支持更加全面，不少特性會直接集成進來。

5) Jetty優化：

1、通常調優的基本過程

1.明瞭須要調優的系統架構

2.設定性能調優的目標

3.明瞭目標當前的性能狀況

4.找出目前的性能瓶頸的所在

5.解決引發性能瓶頸的根本問題

6.重複以上過程直到達到設定目標性能爲止

2、性能指標：

崩潰點：同時多少併發的時候，服務器Down掉？

吞吐量:多少人一塊兒來，都沒問題？

併發數:每秒能處理多少人？

響應時間：每人須要等待的時間多長？

3、調優勢：

1.硬件配置優化：

虛擬機

物理機

CPU 

內存 

 

二、系統優化（Linux)

已經根據門戶的方式去優化。

 

3.JVM參數優化：

-Xms：設置jvm內存的初始大小

-Xmx：設置jvm內存的最大值

-Xmn：設置新域的大小（這個彷佛只對 jdk1.4來講是有效的，後來就廢棄了）

-Xss：設置每一個線程的堆棧大小(也就是說,在相同物理內存下，減少這個值能生成更多的線程)

-XX：NewRatio :設置新域與舊域之比，如-XX：NewRatio = 4就表示新域與舊域之比爲1：4

-XX:NewSize：設置新域的初始值

-XX:MaxNewSize ：設置新域的最大值

-XX:PermSize：設置永久域的初始值

-XX:MaxPermSize：設置永久域的最大值

-XX:SurvivorRatio=n:設置新域中Eden區與兩個Survivor區的比值。（Eden區主要是用來存放新生的對象，而兩個 Survivor區則用來存放每次垃圾回收後存活下來的對象）

監控內存 CPU

常見的錯誤 ：

java.lang.OutOfMemoryError相信不少開發人員都用到過，這個主要就是JVM參數沒有配好引發的，可是這種錯誤又分兩種：java.lang.OutOfMemoryError: Java heap space和

java.lang.OutOfMemoryError: PermGen space，其中前者是有關堆內存的內存溢出，能夠同過配置-Xms和-Xmx參數來設置，然後者是有關永久域的內存溢出，能夠經過配置-XX:MaxPermSize來設置。

 

4.容器優化：

a.線程池

 

線程池線程資源大小肯定了服務器的服務能力

默認大小不必定能知足生產環境

線程分配方式決定了服務器的資源利用效率

固定線程數處理多任務,表明：JDK的ThreadPoolExecutor

以最大線程數爲限處理多任務，表明：Jetty自帶QueuedThreadPool

Work-stealing 分配，Jetty目前沒有這個實現 Jetty中配置實例：

 

 

maxThreads：表示最多同時處理的鏈接數。應該將線程數（最大線程數）設置比最大預期負載（同時併發的點擊）多25%（經驗規則）(低配置用戶可經過下降maxThreads並同時增大

acceptCount值來保證系統的穩定)。

acceptCount：當同時鏈接的人數達到maxThreads時，還能夠接收排隊的鏈接。

minSpareThread：指「啓動之後，老是保持該數量的線程空閒等待」；設置比預期負載多25%。

maxSpareThread：指「若是超過了minSpareThread，而後老是保持該數量的線程空閒等待」；設置比預期負載多25%。

其中主要修改兩個參數maxThreads和acceptCount值。增長maxThreads，減小acceptCount值有利縮短系統的響應時間。可是maxThreads和acceptCount的總和最高值不能超過6000，並且

maxThreads過大會增長CPU和內存消耗，故低配置用戶可經過下降maxThreads並同時增大acceptCount值來保證系統的穩定。

connectionTimeout：鏈接超時，最大超時時間，當響應速度慢的時候，經過調整該參數，來平衡正確率和服務器資源的回收。

 

b.Connectors

選擇Connector時，須要考慮應用自身的特色，例如股票、聊天室.

TCP 鏈接數 Keep-Alive Java BIO Connectors SocketConnector (HTTP) 

Ajp13SocketConnector (AJP) SslSocketConnector(SSL)

Java NIO Connectors electChannelConnector(HTTP) SslSelectChannelConnector(SSL)

 

Acceptors 表示同時在監聽read事件的線程數

默認值是 1 典型值範圍 1~(處理器內核數+1) 

對於NIO 來講，設置爲(處理器內核數+1)比較合適

maxIdleTime 表示鏈接最大空閒時間 默認值是 200000，通常這個值都太大了

典型值 3000 左右足夠 

對AJP來講通常設置爲-1，表示鏈接須要一直保持

 

LowResourcesMaxIdleTime 表示線程資源稀少時的maxIdleTime 默認值是 -1，表示沒有設置 

通常設置值應該<=maxIdleTime

lowResourcesConnections 只有NIO纔有這個設置，表示鏈接空閒時的鏈接數，大於這個數將被shutdown 

默認值是 0,表示該設置沒有生效 每一個acceptor的鏈接數=(lowResourcesConnections+acceptors-1)/acceptors

 

AcceptQueueSize 鏈接被 accept 前容許等待的鏈接數即Socket的Backlog ，默認 50

SoLingerTime 具備指定逗留時間（以毫秒爲單位) 即socket的setSoLinger，默認關閉

ResolveNames 是否反查 getRemoteHost() 默認false

 

c.JVM

Jetty性能調優勢-JVM

JVM參數調整主要涉及兩個方面 

堆/棧內存大小調整 

Xmx/xms 最大/最小堆大小 

xmn 新生代大小 

-XX:MaxPermSize 持久代堆大小 

垃圾分配回收算法考慮暫停時間、吞吐量選擇不一樣算法 

串行/並行/併發收集

 

d.Content Cache

動態內容不會被cache 靜態內容纔會被cache

maxCacheSize 256,000,000

maxCachedFileSize 200,000,000

maxCachedFiles ?2,048

useFileMappedBuffer ?true

能夠經過etc/webdefault.xml配置

 

e.冗餘組件去除

去除多餘的Connector 去除不須要的構建Handler 例如SessionHandler,ServletHandler

關閉沒必要要的服務 例如 jmx-console。(JBoss)

 

5.代碼優化：

在高峯期，減去日誌記錄的操做，或者把日誌暫時先緩存起來，使用異步處理的方式。

減小一些數據庫操做。

減小NC 身份證等匹配方式。

 

6.數據庫優化：

索引

視圖

 

7.其餘：

壓縮css,js,圖片

使用瀏覽器緩存

CDN加速

分佈式緩存服務器

集羣、負載均衡

 

三.調優策略：

a.關鍵點，找到瓶頸,給瓶頸分配更多的資源，或者減輕其工做量。

 

4、調優原則

a.每臺服務器，所能承載的參數，都會有差別，尤爲是內存 CPU的配置不一致。

b.每種服務所需的計算資源各不相同，要根據服務的偏向不一樣，而去把最好的資源，分配到最須要的地方

c.性能優化，是永恆的話題，沒有永久最優解，只能查出目前最優解,是一個不斷優化的過程。

 

5、調優技巧

1.粗狂的掃點與詳細的指標相結合，儘可能讓驗證調優的過程更敏捷,讓主要的指標穩定下來，在肯定指標前，再使用詳細的方式去測出各類指標。

2.分輪測試，在測試結果中，找出各個參數的規律。爲調優提供指導數據。

3.在程序增長計數器，驗證LR的請求次數。

4.在程序每一個步驟，增長多一些時間，檢查下，究竟是卡在哪一個步驟，尤爲是操做數據庫先後。