1、所需的jar包(jsp2.1):

• servlet-api-2.5-6.x.jar
• jetty-util-6.x.jar
• jetty-6.x.jar
• ant-1.6.5.jar
• core-3.1.1.jar
• jsp-2.1.jar
• jsp-api-2.1.jar

2、示例代碼片段：

Jetty 當前版本為6.1.x，支持servlet2.5、jsp 2.1/2.0。（http://docs.codehaus.org/display/JETTY）

jetty主要的jar為jetty-6.1.1.jar，servlet-api-2.5-6.1.1.jar，jetty-util- 6.1.1.jar。啟動的jar 為start.jar。還有jsp規范的jar。jsp2.1,好像已經減了不少的jar了，只有4個文件core-3.1.1.jar，ant- 1.6.5.jar，jsp-2.1.jar，jsp-api-2.1.jar。core是使用eclipse的jdt，進行jsp編譯。

jetty的主要配置文件為etc/jetty.xml，當然你可以自己指定別的文件。在start.jar中有個start.config文件是默認的環境配置，以及指定默認的配置文件。可以手工替換。

    啟動jetty很簡單，在命令行下面java -jar start.jar；如果需要指定start.config，使用java -DSTART=start.config -jar start.jart；配置web 應用也非常的簡單：更改jetty.xml就行了，增加web應用的方式包括，直接放置應用在webapps下面，或者配置以下的context

配置Virtual hosts:

context配置($JETTY-HOME/contexts/javadoc.xml)：

默認webapp目錄配置：


默認的web.xml配置文件為webdefault.xml，如果想配置相應的web參數，可以更改其應用。默認的端口為8080,如果想修改，更改：jetty.port屬性

更詳細的配置信息可查詢官網。
http://wiki.forum.nokia.com/index.php/%E4%B8%AD%E6%96%87_J2ME%E4%B8%AD%E6%96%87%E7%BC%96%E7%A0%81%E9%97%AE%E9%A2%98
該文展示如何結合使用 Jetty servlet 引擎和 DWR 簡捷有效地實現一個 Comet Web 應用程序，以及其中的一些細節及原理。

文章地址：http://www.ibm.com/developerworks/cn/java/j-jettydwr/

一些問題：
１、web.xml配配置，DWR使用2.0RC3以下版本時須全用選項：pollAndCometEnabled代替activeReverseAjaxEnabled，如下：

選項說明（http://getahead.org/dwr/server/servlet 可查詢更多參數的說明）：
1)、activeReverseAjaxEnabled
true 表示激活輪詢和 Comet 功能。2.0 RC3以前版本，參數名為：pollAndCometEnabled。

2)、initApplicationScopeCreatorsAtStartup　通知 DWR 在應用程序啟動時初始化 ReverseAjaxTracker。這將在對 bean 生成第一個請求時改寫延遲初始化（lazy initialization）的常規行為 —— 在本例中這是必須的，因為客戶機不會主動對 ReverseAjaxTracker 調用方法。
里面有很多DWR使用的經驗技巧，有一定的參考價值：

http://www.javatang.com/archives/tag/dwr
1、實現DWR跨域支持

a.配置web.xml文件，dwr定義時加入以下參數設置：

b.客戶端調用：

更詳細的說明可參見官網 Remoting Options 章節（http://getahead.org/dwr/browser/engine/options）。

2、DWR的Session支持

DWR通過 WebContext / WebContextFactory 來取得HttpServletRequest、HttpServletResponse、HttpSession、ServletContext、 ServletConfig等對象。（DWR2.0）實現可參見DWR內部腳本，engine.js文件"dwr.engine._getJSessionId"部份代碼。

更多詳細信息見官網API：http://getahead.org/dwr/server/javaapi。

所以SESSION根據jsessionid來確定的，jsessionid存放在cookie中，若客戶端禁止cookie的話，jsessionid每次都新生成，所以無法確保在服務端的SESSION唯一。跨域調用DWR時，瀏覽器默認禁止第三方cookie，所以會有正常使用SESSION功能。設置Internet選項，"隱私"，"高級"，開始對第三方cookie的支持，即可解決這個問題。

http://luoyuzj911.javaeye.com/blog/148817
http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/protocol-support.html
(來源測試時代,http://www.testage.net)

多數人對怎樣去分析工具收集到的測試結果感到無從下手，下面我就把個人工作中的體會和收集到的有關資料整理出來，希望能對大家分析測試結果有所幫助。

分析原則：
    • 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）
    • 查找瓶頸時按以下順序，由易到難。
    服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）
    注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
    • 分段排除法 很有效

分析的信息來源：
    •1 根據場景運行過程中的錯誤提示信息
    •2 根據測試結果收集到的監控指標數據

一．錯誤提示分析

分析實例：
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析：
•A、應用服務死掉。
   （小用戶時：程序上的問題。程序上處理數據庫的問題）
•B、應用服務沒有死
   （應用服務參數設置問題）
    例：在許多客戶端連接Weblogic應用服務器被拒絕，而在服務器端沒有錯誤顯示，則有可能是Weblogic中的server元素的 AcceptBacklog屬性值設得過低。如果連接時收到connection refused消息，說明應提高該值，每次增加25％
•C、數據庫的連接
   (1、在應用服務的性能參數可能太小了 2、數據庫啟動的最大連接數（跟硬件的內存有關）)

2  Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成
•A、應用服務參數設置太大導致服務器的瓶頸
•B、頁面中圖片太多
•C、在程序處理表的時候檢查字段太大多

二．監控指標數據分析

1．最大并發用戶數：
應用系統在當前環境（硬件環境、網絡環境、軟件環境（參數配置））下能承受的最大并發用戶數。
在方案運行中，如果出現了大于3個用戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。
如果測得的最大并發用戶數到達了性能要求，且各服務器資源情況良好，業務操作響應時間也達到了用戶要求，那么OK。否則，再根據各服務器的資源情況和業務操作響應時間進一步分析原因所在。

2．業務操作響應時間：
• 分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖，可以確定在方案執行期間響應時間過長的事務。
• 細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起的？問題是否與網絡或服務器有關？
• 如果服務器耗時過長，請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能下降的原因。如果網絡耗時過長，請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題
3．服務器資源監控指標：
內存：
    1 UNIX資源監控中指標內存頁交換速率（Paging rate），如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。

    2 Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高，同時Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。

內存資源成為系統性能的瓶頸的征兆:
    很高的換頁率(high pageout rate);
    進程進入不活動狀態;
    交換區所有磁盤的活動次數可高;
    可高的全局系統CPU利用率;
    內存不夠出錯(out of memory errors)

處理器：
    1 UNIX資源監控（Windows操作系統同理）中指標CPU占用率（CPU utilization），如果該值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。如果服務器專用于SQL Server,可接受的最大上限是80-85%
    合理使用的范圍在60%至70%。
    2 Windows資源監控中，如果System\Processor Queue Length大于2，而處理器利用率（Processor Time）一直很低，則存在著處理器阻塞。

CPU資源成為系統性能的瓶頸的征兆:   
     很慢的響應時間(slow response time)
     CPU空閑時間為零(zero percent idle CPU)
     過高的用戶占用CPU時間(high percent user CPU)
     過高的系統占用CPU時間(high percent system CPU)
    長時間的有很長的運行進程隊列(large run queue size sustained over time)

磁盤I/O：
    1 UNIX資源監控（Windows操作系統同理）中指標磁盤交換率（Disk rate），如果該參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統。
    2 Windows資源監控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。

I/O資源成為系統性能的瓶頸的征兆 :
     過高的磁盤利用率(high disk utilization)
    太長的磁盤等待隊列(large disk queue length)
    等待磁盤I/O的時間所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))
    太長的運行進程隊列，但CPU卻空閑(large run queue with idle CPU)

4．數據庫服務器：
SQL Server數據庫：
    1 SQLServer資源監控中指標緩存點擊率（Cache Hit Ratio），該值越高越好。如果持續低于80%，應考慮增加內存。
    2 如果Full Scans/sec（全表掃描/秒）計數器顯示的值比1或2高，則應分析你的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被優化。
    3 Number of Deadlocks/sec(死鎖的數量/秒)：死鎖對應用程序的可伸縮性非常有害，并且會導致惡劣的用戶體驗。該計數器的值必須為0。
   4 Lock Requests/sec(鎖請求/秒)，通過優化查詢來減少讀取次數，可以減少該計數器的值。

Oracle數據庫：
  1 如果自由內存接近于0而且庫快存或數據字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL區）和數據字典快存的命中率：
   select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由內存：    select * from v$sgastat where name=’free memory’;
2 如果數據的緩存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS參數的值（單位：塊）。
  緩沖區高速緩存命中率：
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志緩沖區申請的值較大，則應加大LOG_BUFFER參數的值。
    日志緩沖區的申請情況 ：
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果內存排序命中率小于0.95，則應加大SORT_AREA_SIZE以避免磁盤排序 。
   內存排序命中率 ：
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注：上述SQL Server和Oracle數據庫分析，只是一些簡單、基本的分析，特別是Oracle數據庫的分析和優化，是一門專門的技術，進一步的分析可查相關資料。

問題描述：
原來一直運行正常的Mysql，突然無法運法連接，查詢。啟動Mysql后，雖然進程建立，但/tmp/mysql.socket沒有生成，客戶端無法連接到數據庫，也不能正常停止數據庫，只能通過殺進程來停止服務。

解決方法：
查詢數據庫日志，data/pc-name.err，發現“/usr/local/mysql/bin/mysqld: Disk is full writing './mysql-bin.000124' (Errcode: 28). Waiting for someone to free space... Retry in 60 secs”，查看硬盤空間(df)，果然/usr分區已經滿了，清理分區后，重啟Mysql，一切正常。


另：/data/目錄下，有若干mysql-bin.000***的文件，從mysql-bin.000001開始一直排列下來，而且有的占用了大量硬盤空間。網上搜了一下，得知此乃MySQL的事務日志，logbin主要是用來做回滾和增量備份的。刪除復制服務器已經拿走的binlog是安全的，一般來說網絡狀況好的時候，保留最新的那一個足以。(缺點是將無法使數據庫恢復先前的狀態)