2007年9月11日
#
某天，停車，圖方便隨便停在路邊，抱怨了兩句，ld隨即頂回一句：“只要有邊就能停”
一直認(rèn)為lob類型的性能要好過long，但是之前只了解到long的種種限制，oracle也是不推薦使用long類型，這幾天由于一個(gè)項(xiàng)目問題，產(chǎn)品里面一個(gè)表字段用了long類型，分析下來操作long的時(shí)候，性能有所影響，想把它改成lob，就簡單驗(yàn)證了一下
首先創(chuàng)建兩個(gè)測試表：
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼，往兩個(gè)表里面各插入100條數(shù)據(jù)，保證插入數(shù)據(jù)是一樣的，lob字段長度為10k（如果小于4k，oracle可以把它保存到到表內(nèi)，不會(huì)存儲(chǔ)在表外，性能沒有問題，這個(gè)我基本確定，而且我們應(yīng)用中這個(gè)字段經(jīng)常會(huì)超過4k）。
做一個(gè)簡單查詢對比一下：
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統(tǒng)計(jì)信息
----------------------------------------------------------
331 recursive calls
0 db block gets
69 consistent gets
4 physical reads
0 redo size
1278 bytes sent via SQL*Net to client
837 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select * from test_long where a=1;
統(tǒng)計(jì)信息
----------------------------------------------------------
236 recursive calls
0 db block gets
43 consistent gets
0 physical reads
0 redo size
675 bytes sent via SQL*Net to client
531 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
5 sorts (memory)
0 sorts (disk)
1 rows processed
對比一下，long開銷比lob小，當(dāng)然你可以把lob字段啟用緩存，把4次物理讀去掉，但還是多了（73-43）次邏輯讀，update也試了一下，lob產(chǎn)生的redo比long大，就不列出來了，有興趣的可以自己試試
測試下來，看來之前的認(rèn)識(shí)不對，不確定的東西最好還是動(dòng)手試試，當(dāng)然對于新應(yīng)用，還是不建議用long，畢竟oracle已經(jīng)廢棄它了。
testClobLong.java
用遠(yuǎn)程桌面連接登入服務(wù)器的時(shí)候，你可能會(huì)經(jīng)常碰到下面的情況：
也就是說，服務(wù)器的連接數(shù)已經(jīng)滿了，很多時(shí)候，可能是別人異常斷開連接，導(dǎo)致連接沒有釋放，一般這時(shí)候你需要去機(jī)房登入服務(wù)器斷開連接，其實(shí)windows提供了tsdiscon命令來做這事情
有時(shí)候，我們可能希望看到lr的出錯(cuò)頁面：比如lr出錯(cuò)，但是后臺(tái)服務(wù)器沒有錯(cuò)誤日志，這時(shí)候，我們希望能看到錯(cuò)誤頁面的內(nèi)容來判斷問題出在什么地方，但是lr沒有提供類似的功能
我們可以通過一種變通的辦法來實(shí)現(xiàn)：
首先找到你出錯(cuò)的頁面，保存該頁面到參數(shù)里面：
web_set_max_html_param_len(“2048”);
web_reg_save_param(“FILED”,”LB=”,”RB=”,”Search=Body”,LAST);
然后輸出到日志里面： lr_output_message(”#######################################%s”,lr_eval_string(”{FILED}”));
修改lr run-time的幾個(gè)設(shè)置：
1、Always send messages
2、continue on error （這樣才能保證運(yùn)行l(wèi)r_output_message)
這樣lr會(huì)把所有的lr_output_message輸出保存到日志文件
當(dāng)然你不要下載資源文件，否則保存到的就不是html頁面了，可能是一個(gè)gif :(
最后，結(jié)合lr controller的錯(cuò)誤信息，定位到出錯(cuò)的vuser id，查看該vuser的log文件就能看到錯(cuò)誤頁面了
非常有效的一個(gè)小技巧，用它解決了一個(gè)難纏的問題。
慢慢變味了，一群無聊的人整天盯著別人捐了多少，很奇怪
最近一段時(shí)間特別忙，以至于發(fā)生地震這么大的事情都沒注意到，首都人民不斷告訴我被震了也沒當(dāng)回事，昨晚回家打開電視，新聞?lì)l道，懵了，坐下來一直看，到晚上2點(diǎn)，滿目蒼痍，真為處于震中的人揪心，中間鼻子酸了N次，也憤怒了N次（那些惡心人的地方官，難道就不能說點(diǎn)實(shí)際的東西嗎？）
1、政府反映非常迅速
2、子弟兵真好
2、有一個(gè)好總理
3、地方政府不作為，官話套話（被采訪的那個(gè)什么何彪，真想抽丫的）
4、為什么總是學(xué)校？處于地址多發(fā)地帶的學(xué)校和其他公共設(shè)施為什么都是豆腐渣
為所有受難的人祈禱！為我們飽受磨難的祖國祈禱！
公司員工捐款20W，盡點(diǎn)綿力
摘要: 這幾天測試一個(gè)引擎的性能，用一個(gè)單表查詢的case，測試出來的結(jié)果是210tps，cpu也正常，在85%左右，也沒懷疑。
后面再重新測試的時(shí)候，加上了gc log，用gc分析工具分析了一下gc的吞吐量，發(fā)現(xiàn)吞吐量奇低，竟然只有77%左右，很是奇怪，看了一下gc日志，所有都是global gc， 懷疑gc策略有問題，查了一下資料，參考了下面一篇文章：
閱讀全文
Sybase ASE有三種鎖模式：AllPages,DataPages,DataRows
Sybase的數(shù)據(jù)有table pages和index pages，最小分配單位為pages，不同的鎖模式對于table pages和index pages有不同的表現(xiàn)，具體如下：
| Locking Schema | Locks on Index | Locks on Data |
| All Pages | Page | Page |
| DataPages | Not locked | Page |
| DataRows | Not locked | Row |
如上表所示：
1、AllPages鎖模式對于并發(fā)的限制最高，他對index pages和table pages都加頁鎖（當(dāng)頁被鎖住的時(shí)候，頁上的所有rows都不能被其他session訪問）
2、DataPages對table pages加頁鎖
3、DataRows：強(qiáng)烈建議用這個(gè)鎖模式，對于oltp應(yīng)用，如果用前兩種鎖模式會(huì)導(dǎo)致頻繁死鎖
另外，DataPages和DataRows對于index pages的控制采用latch方式，一種輕量級(jí)的鎖機(jī)制（熟悉oracle會(huì)比較清楚）
對于Sybase ASE來說，鎖是非常寶貴的資源，不要長時(shí)間持有鎖，所以一般我們在寫應(yīng)用的時(shí)候盡量減少長事務(wù)
另：Sybase ASE缺省的事務(wù)隔離級(jí)別：Read Committed
一個(gè)用戶點(diǎn)擊就是一個(gè)用戶請求，一個(gè)webservice類似的調(diào)用也算一個(gè)請求，等等
一個(gè)用戶在某個(gè)時(shí)間點(diǎn)上當(dāng)然只能發(fā)起一個(gè)用戶請求，一個(gè)用戶請求就是一個(gè)并發(fā)
我們一般糾纏在同一事物并發(fā)還是不同事務(wù)并發(fā)。
可能在一個(gè)時(shí)間點(diǎn)上，有100個(gè)用戶在發(fā)送瀏覽，查詢動(dòng)作，10個(gè)用戶在下訂單，5個(gè)用戶在做付款動(dòng)作，你說這個(gè)時(shí)間點(diǎn)上有多少個(gè)并發(fā)請求，當(dāng)然是115個(gè)了
衡量一個(gè)系統(tǒng)性能主要靠的就是這個(gè)吞吐量（tps）
當(dāng)然我們也非常關(guān)心同時(shí)100個(gè)用戶并發(fā)下訂單的時(shí)候系統(tǒng)是否能支撐（這是通常我們大部分人理解的并發(fā)），我們會(huì)說這是核心業(yè)務(wù)，我們要得出數(shù)據(jù)（是否要考慮背景業(yè)務(wù)呢，呵呵，很難說的清楚，我一般就不考慮）
某項(xiàng)目，年前開始報(bào)OOM，頻率保持在一月一次，發(fā)生OOM的時(shí)候，heap free size還有7～800M，比較奇怪，年后系統(tǒng)上集群，系統(tǒng)發(fā)生OOM的頻率開始變得頻繁，基本在4-5天，由于用的是sun jdk 1.4.2_08，無法獲取到heap dump，建議用戶升級(jí)到1.4.2_14（該版本以后sun添加了HeapDumpOnOutOfMemoryError參數(shù)，便于獲取dump幫助診斷該類問題），4天之后，我們獲取到了heapdump文件，通過對dump的分析，基本上排除了對象泄漏。
根據(jù)環(huán)境（64bit Solaris + 32bit JDK），客戶把Heap最大設(shè)置為2G，開始懷疑32bit JDK無法分配這么大的Heap，經(jīng)過驗(yàn)證，不存在這樣的問題（sun網(wǎng)站也有相關(guān)說明，在solaris 64bit系統(tǒng)上，32bit jdk最大可以設(shè)置到4G）
但是從dump看到application classes loader大小已經(jīng)到了60M以上，有點(diǎn)懷疑Perm區(qū)設(shè)置太小導(dǎo)致，查了一下sun的文檔，Perm區(qū)缺省大小為64M，估計(jì)是應(yīng)用加載太多classes導(dǎo)致Perm區(qū)溢出，
我們也簡單模擬了一下Perm溢出，強(qiáng)制設(shè)置max perm大小為32M，并對GC進(jìn)行了監(jiān)控，結(jié)果和我們預(yù)想的一致，看下面的gc log：
151.836: [Full GC 151.836: [Tenured: 25735K->25736K(1048576K), 0.8380858 secs] 25911K->25736K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8382804 secs]
152.676: [Full GC 152.676: [Tenured: 25736K->25722K(1048576K), 0.8464782 secs] 25752K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8466638 secs]
153.525: [Full GC 153.525: [Tenured: 25722K->25724K(1048576K), 0.8419056 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8420986 secs]
154.368: [Full GC 154.368: [Tenured: 25724K->25724K(1048576K), 0.8398816 secs] 25724K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8400498 secs]
155.212: [Full GC 155.212: [Tenured: 25724K->25725K(1048576K), 0.8365448 secs] 25788K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8367370 secs]
156.050: [Full GC 156.050: [Tenured: 25725K->25722K(1048576K), 0.8422488 secs] 25725K->25722K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8424328 secs]
156.895: [Full GC 156.895: [Tenured: 25722K->25724K(1048576K), 0.8443532 secs] 25738K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8445450 secs]
157.740: [Full GC 157.741: [Tenured: 25724K->25724K(1048576K), 0.8427754 secs] 25740K->25724K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8429634 secs]
158.587: [Full GC 158.588: [Tenured: 25724K->25726K(1048576K), 0.8352290 secs] 25820K->25726K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8354212 secs]
159.424: [Full GC 159.424: [Tenured: 25726K->25723K(1048576K), 0.8435336 secs] 25726K->25723K(1557568K), [Perm : 32767K->32766K(32768K)], 0.8437092 secs]
160.270: [Full GC 160.270: [Tenured: 25723K->25725K(1048576K), 0.8477722 secs] 25739K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8479596 secs]
161.119: [Full GC 161.119: [Tenured: 25725K->25725K(1048576K), 0.8543338 secs] 25725K->25725K(1557568K), [Perm : 32767K->32767K(32768K)], 0.8545040 secs
從日志看，和我們現(xiàn)場的狀況非常相似，heap空間充足，但是perm已經(jīng)到了32M，無法再進(jìn)一步分配空間，直接導(dǎo)致jvm頻繁做Full GC，控制臺(tái)也開始拋出OOM（Perm引起的回收都是full gc），這樣看基本我們判斷是Perm太小，導(dǎo)致無法加載classes導(dǎo)致的
和客戶溝通之后，我們本來打算進(jìn)一步驗(yàn)證（在生產(chǎn)環(huán)節(jié)打開PrintGCDetail，獲取詳細(xì)的GC log），后面仔細(xì)檢查nohup.out,發(fā)現(xiàn)里面已經(jīng)拋出了 OutOfMemoryError:PermGen Space，至此我們確定是Perm設(shè)置不合理導(dǎo)致了本次事故，和客戶確認(rèn)之后，我們在啟動(dòng)參數(shù)中加上了MaxPermSize
后面想到中間上了集群之后，eos加載了大量的jboss cache class，這也直接解釋了為什么這段時(shí)間OOM出現(xiàn)的頻率比之前更頻繁的原因
這里總結(jié)一下，希望對碰到類似問題的tx有借鑒意義，強(qiáng)烈建議用sun jdk 1.4.2的同學(xué)升級(jí)到>=1.4.2_12，便于對OOM問題的診斷，并加上GC log協(xié)助驗(yàn)證。
這里再介紹一下JVM發(fā)生OOM的幾種情況：
1、java.lang.OutOfMemoryError: Java heap space
這是我們平常理解的OOM，是由于heap space確實(shí)沒有空間分配，這種一般是由于內(nèi)存泄漏導(dǎo)致，也有可能是heap space設(shè)置太小。需要具體分析
2、java.lang.OutOfMemoryError: PermGen space
jvm規(guī)范里面有定義一個(gè)method space，這里主要放classes和method list和一個(gè)string pool，string有一個(gè)intern方法，通過這個(gè)方法定義的string都放在這里（好像不常用），這里設(shè)置不太小會(huì)導(dǎo)致OOM，缺省64M，主要由于現(xiàn)在應(yīng)用依賴的第三方類越來越多，導(dǎo)致這類問題頻繁發(fā)生，需要引起重視
3、Requested array size exceeds VM limit
這種是由于申請的array size超出了heap space大小，比如在一個(gè)256M的heap space中申請一個(gè)512M的array，這種基本都是應(yīng)用bug導(dǎo)致
4、request <size> bytes for <reason>. Out of swap space?
這種是由于heap size設(shè)置相對于系統(tǒng)物理內(nèi)存太大，導(dǎo)致系統(tǒng)swap space不足，這種的解決辦法就是減小heap size大小
5、<reason> <stack trace> (Native method)
這種估計(jì)是最麻煩的了，也是最少碰到的，是由于jni或native method導(dǎo)致，如果自己沒有寫這類的東西，基本可以說是jdk問題
之前就準(zhǔn)備了一堆的片子，好好享受了一把，留下幾部有映象的吧：
強(qiáng)烈推薦型：
咱們自家的片子先推薦：《盲山》
看盲山，讓我想起Michael Moore，我一直認(rèn)為，嚴(yán)肅題材的電影本身就是電影存在的意義所在，我們需要用影像真實(shí)的記錄這個(gè)時(shí)代，我們需要這些“冷名人”，他們也許不是名利場的寵兒，但是他們一樣會(huì)有無數(shù)喜歡他們的人
《我在伊朗長大》
聽主人公瑪嘉娓娓道來，伊朗社會(huì)的變遷，依稀可以看到我們的影子，影片沒有去譴責(zé)或者反省或者什么高深的立意，只是要告訴你這個(gè)社會(huì)的樣子
《進(jìn)退維谷》
只要是Paul Haggis，都值得你關(guān)注，呵呵，反戰(zhàn)的片子，我感覺比之前的撞車有過之而無不及，不知為啥挺冷的，Tommy應(yīng)該提名最佳男演員，不過他好像評(píng)老無所依提名
《偷心》
老片子，看吧，不后悔，愛死這個(gè)精靈古怪的Natalie了，哈哈，真真假假誰又能分得清楚呢
《老無所依》
那個(gè)僵尸男實(shí)在太酷了，Tommy今年也挺火的，哈哈
隨便看看：
神探，喜歡記憶碎碎片，搏擊俱樂部這類片子的人可以看看，劉青云的表演我個(gè)人覺得一般，反正也就
美國黑幫（Denzel Washington新片，值得一看）
諜影重重3（這個(gè)還是比較經(jīng)典，今年馬特達(dá)蒙很火，整部片子非常緊湊，緊張刺激），
我的盛大同志婚禮（無厘頭Adam Sandler，去年的神奇遙控器記憶猶新），
一年到頭（騙了我一把眼淚）
C+偵探
贖罪（最近很火，看看吧）
哈哈，不記得了，還有一些，另外看了第一季反恐24，感覺一般
http://www.tudou.com/programs/view/yKJB_VzHXYU/
突然覺得，這一年收獲很多，感觸很多，需要仔細(xì)總結(jié)總結(jié)
應(yīng)該來說，場面還是不錯(cuò)的，國內(nèi)戰(zhàn)爭大片
太追求效果了，說實(shí)話，看過之后就忘了，在腦海里沒留下啥東西，雖然沒經(jīng)歷過戰(zhàn)爭，但是在解放戰(zhàn)爭年代的巷戰(zhàn)竟然打著手勢，為演戲而演戲，挺搞笑的，懷念黑鷹墜落中的那段伏擊戰(zhàn)，谷子地站在空地里手舞足蹈那段看著太怪了，這是戰(zhàn)爭嗎，整個(gè)讓人感覺挺滑稽的，像一群新兵蛋子第一次上戰(zhàn)場，哭爹喊娘，太過啦馮導(dǎo)
耳朵被轟的夠嗆，后面開始打感情牌，賺點(diǎn)眼淚
馮導(dǎo)還是要加油啊，其實(shí)大家是喜歡看馮導(dǎo)還是葛優(yōu)呢，哈哈
之前一直認(rèn)為類似：where timestamp>date 這種子句是不走索引的
下面簡單做一個(gè)驗(yàn)證：
c:>sqlplus / as sysdba
sys@EOS >create table test as select table_name,to_timestamp(last_analyzed) date_test from dba_tables;
表已創(chuàng)建。
sys@EOS> create index idx_test_date on test (date_test);
索引已創(chuàng)建。
sys@EOS> desc test
名稱 是否為空? 類型
----------------------------------------------------- -------- ----------------
--------------------
TABLE_NAME NOT NULL VARCHAR2(30)
DATE_TEST TIMESTAMP(0)
sys@EOS> select date_test from test where date_test > TO_DATE('2007-11-5 00:00:00','yyyy-MM-dd HH24:mi:ss');
執(zhí)行計(jì)劃
----------------------------------------------------------
Plan hash value: 944171586
-------------------------------------------------------------------------------- --
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------- --
| 0 | SELECT STATEMENT | | 1 | 22 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| IDX_TEST_DATE | 1 | 22 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------- --
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("DATE_TEST">TIMESTAMP'2007-11-05 00:00:00')
Note
-----
- dynamic sampling used for this statement
統(tǒng)計(jì)信息
----------------------------------------------------------
7 recursive calls
0 db block gets
18 consistent gets
0 physical reads
0 redo size
280 bytes sent via SQL*Net to client
374 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
從上面可以清楚看到，timestamp>date情況下，走索引
糾正我之前的認(rèn)識(shí)。
另外再補(bǔ)充一下，date這個(gè)數(shù)據(jù)類型一般情況下很少用，建議產(chǎn)品里面所有的date數(shù)據(jù)類型全部改為timestamp
作者：tacy lee
由于大量開源框架的采用，Classes沖突的問題在我們的項(xiàng)目中越來越常見，下面寫了一個(gè)簡單的jsp，用來查找當(dāng)前使用類的位置：
<%@page contentType="text/html; charset=gb2312" %>
<html>
<head>
<title>Class conflict</title>
</head>
<body>
Example input: com.primeton.tp.web.driver.webdriver.PageDriver<br>
<form action="<%=request.getRequestURI()%> " method="post">
<input type="text" name="className" size="50" ><br>
<input type="submit" value="submit">
</form>
<%
String classLocation = null;
String className =request.getParameter("className");
if ((className != null) && ((className = className.trim()).length() != 0)) {
try{
classLocation = Class.forName(className).getProtectionDomain().getCodeSource().toString();
}catch(Throwable e){
log("error=" + e, e);
}
if (classLocation != null) {
out.println("Class " + className + " found in <br>" + classLocation );
}
else {
out.println("Class '" + className + "' not found" );
}
}
%>
</body>
<html>
通過這個(gè)jsp頁面可以輸入需要查詢的類
-----------------------------------------------------------------------------------------------------------------------------------------------------
另外，websphere可以通過下面兩個(gè)方法來改變類的加載：
1、在"Applications" >"Enterprise Applications" >" yourear ">" Class Loading and File Update Detection"
修改："Class loader mode" 為 "Parent Last"，這樣應(yīng)用類可以覆蓋父裝載器的類
當(dāng)然但如果你混合使用了被覆蓋的類和沒有被覆蓋的類，則此操作有可能會(huì)導(dǎo)致 ClassCastException 或 LinkageErrors
2、在"Servers" > "Application servers" > "yourserver" > "Process Definition" > "Java Virtual Machine"
添加CLASSPATH，讓你的類先加載
如果你使用gtalk，你可以使用google最近提供的翻譯機(jī)器人幫你翻譯
只需要添加如下兩個(gè)機(jī)器人帳號(hào)到你的gtalk好友列表中：
en2zh@bot.talk.google.com
zh2en@bot.talk.google.com
嘿嘿，你就可以讓他們幫你翻譯啦！
google另外提供很多其他語言的機(jī)器人，有興趣的可以去了解一下
官網(wǎng)已經(jīng)發(fā)布消息，好像原定應(yīng)該是21號(hào)發(fā)布嘛！
具體看
這里
-----------------------------------------------------------------------------------
update：
已經(jīng)成功把自己的firefox升級(jí)到3，升級(jí)過程中，用的幾個(gè)插件手動(dòng)調(diào)了一下版本限制，其中g(shù)oogle toolbar和yahoo的delicious不行，刪除之，變通方案：
1、google toolbar我平時(shí)主要用來屏幕取詞，用backword替代
2、yahoo的delicious用老版本替代（delicious沒被收購時(shí)發(fā)布的那個(gè)）
用下來感覺速度確實(shí)快了很多，內(nèi)存占用也少了，原來動(dòng)不動(dòng)就給我奔200M，現(xiàn)在穩(wěn)定在90M左右，經(jīng)常訪問的一些網(wǎng)站都顯示正常。
當(dāng)然這里不是鼓勵(lì)大家升級(jí)，如果你平時(shí)用到一些大塊頭的插件，那最好等他們升級(jí)
列一下我用到的幾個(gè)插件：
Adblock Plus：廣告屏蔽，這個(gè)不用多說了
backword：屏幕取詞，主要是咱們英文太爛，看英文網(wǎng)站需要
del.icio.us：美味書簽，換成了delicious沒被yahoo收購時(shí)開發(fā)的，少了側(cè)邊欄查找，唯一遺憾
DictionarySearch：通過thefreedictionary查單詞(英英)，強(qiáng)烈推薦
FlashGot：下載管理器
Tab Control：沒用那個(gè)龐大無比的Tab Mix Plus，這個(gè)很小，只是實(shí)現(xiàn)新打開的tab在當(dāng)前tab左邊，不要給我跑到最后去
Torbutton：洋蔥頭，翻墻用的
Vimperator：這個(gè)一般人估計(jì)不會(huì)用，只推薦給vi老手
作者：tacy lee
有用Websphere做過項(xiàng)目的人可能都知道，ibm一般都建議在Websphere前面加一個(gè)IHS來做webserver，據(jù)說這樣性能會(huì)提高30%左右，這樣說是否有道理呢，下面我做了一個(gè)簡單的測試來驗(yàn)證：
測試環(huán)境：
硬件：
應(yīng)用服務(wù)器：Dell6600
壓力測試客戶端：自用筆記本（T2050 1.6G)
軟件：
系統(tǒng)：CentOS 4.4
Websphere 6.0.2.17+IHS6.0.2.17（部署在同一臺(tái)機(jī)器上）
首先配置好Websphere和IHS，發(fā)布一個(gè)簡單的測試應(yīng)用，用loadrunner來測試一下不同的組合看看（錄制一個(gè)打開首頁就可以了），下面是我的測試數(shù)據(jù)：
| 測試方法 | 每秒處理請求數(shù) | 響應(yīng)時(shí)間 | 服務(wù)器CPU |
| 直接請求Websphere | 4600/s | 0.013s | 28% |
| 通過IHS轉(zhuǎn)發(fā)請求 | 6800/s | 0.009s | 26% |
數(shù)據(jù)顯示，這還不是一點(diǎn)點(diǎn)提升，竟然快接近50%，把靜態(tài)資源放置到IHS中測試了一把，基本和通過IHS轉(zhuǎn)發(fā)差不多，稍微有些提升，不過放到IHS中可以方便Cache（Edge Server就包括了Caching Proxy component）
下面記錄一下如何放置靜態(tài)資源文件到IHS中：
1、打開Plugins中的plugin-cfg.xml，修改如下內(nèi)容：
<UriGroup Name="default_host_eos_URIs">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*.do"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eosmgr/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/axis2/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/eoshome_deploy/*"/>
</UriGroup>
也可以通過修改WEB-INF下ibm-web-ext.xmi中的fileServingEnabled為false，然后重新生成plugin-cfg.xml，但是我試了一下好像不好用。
另外Websphere（fixpacks 5.1.1.17, 6.0.2.25 and 6.1.0.15）之后的版本給Webcontainer增加了一個(gè)自定義參數(shù)
com.ibm.ws.webcontainer.disallowAllFileServing
設(shè)定它為true產(chǎn)生同樣的效果（而且他會(huì)覆蓋ibm-web-ext.xmi中的設(shè)置）。
2、拷貝你的所有資源文件到IHS的Root Directory中
3、重啟IHS
作者：tacy lee
經(jīng)常，我們在啟動(dòng)應(yīng)用的時(shí)候發(fā)現(xiàn)系統(tǒng)需要的端口被別的程序占用，如何知道誰占有了我們需要的端口，很多人都比較頭疼，下面就介紹一種非常簡單的方法，希望對大家有用
假如我們需要確定誰占用了我們的9050端口
1、Windows平臺(tái)
在windows命令行窗口下執(zhí)行：
C:\>netstat -aon|findstr "9050"
TCP 127.0.0.1:9050 0.0.0.0:0 LISTENING 2016
看到了嗎，端口被進(jìn)程號(hào)為2016的進(jìn)程占用，繼續(xù)執(zhí)行下面命令：
C:\>tasklist|findstr "2016"
tor.exe 2016 Console 0 16,064 K
很清楚吧，tor占用了你的端口
2、AIX
$netstat -Aan|grep 30542
f10000f303321b58 tcp4 0 0 *.30542 *.* LISTEN
$rmsock f10000f303321b58 tcpcb
The socket 0x3321800 is being held by proccess 692476 (db2sysc).
這個(gè)我就不解釋了
3、Linux
$netstat -pan|grep 2809
tcp 0 0 0.0.0.0:2809 0.0.0.0:* LISTEN 9493/java
del.icio.us Tags:
aix,
windows,
tips
作者：tacy lee
今天在配置confluence郵件功能的時(shí)候，啟動(dòng)sendmail竟然需要很長時(shí)間，網(wǎng)上查了查，有很多人碰到類似問題，但是一般都是關(guān)掉sendmail服務(wù)或者關(guān)掉dns了事，咱們現(xiàn)在要用它，自然不能關(guān)掉了事，dns也不能關(guān)，關(guān)了服務(wù)器沒法解析域名
毫無疑問，sendmail去做dns lookup，并且無法lookup到域名，在等待解析超時(shí)！
resolv里面也指定了nameserver，應(yīng)該能正常做dns解析了，既然他無法解析域名，自然這是個(gè)本地域名，難道是hosts里面的問題，查看了一下hosts文件：
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.1.28 rdosrv
好像也沒發(fā)現(xiàn)啥不對的，他在解析啥呢，看看log去，找到/var/log/maillog（也可能在messages），看到如下內(nèi)容：
Dec 11 14:25:01 rdosrv sendmail[22710]: starting daemon (8.13.8): SMTP+queueing@01:00:00
Dec 11 14:25:01 rdosrv sm-msp-queue[22717]: My unqualified host name (rdosrv) unknown; sleeping for retry
Dec 11 14:28:08 rdosrv sendmail[22803]: My unqualified host name (rdosrv) unknown; sleeping for retry
Dec 11 14:35:23 rdosrv sendmail[22944]: My unqualified host name (rdosrv) unknown; sleeping for retry
Dec 11 14:35:57 rdosrv sendmail[22962]: My unqualified host name (rdosrv) unknown; sleeping for retry
Dec 11 14:36:54 rdosrv sendmail[22979]: My unqualified host name (rdosrv) unknown; sleeping for retry
竟然是無法解析rdosrv，有點(diǎn)意思，直接去ping rdosrv自然是沒問題，突然想到好像FQDN里面規(guī)定域名必須用"."結(jié)尾，難道是hosts里面少了一個(gè)"."，嘗試修改hosts文件：
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.1.28 rdosrv. rdosrv
啟動(dòng)sendmail，刷一下就啟動(dòng)了，呵呵
回頭想想，問題其實(shí)很簡單，但是在網(wǎng)上卻沒找到什么好的方案，說明都挺懶得，能繞都繞過去了.
作者：tacy lee
在應(yīng)用使用過程中，我們經(jīng)常會(huì)碰到應(yīng)用響應(yīng)時(shí)間很慢，甚至沒有響應(yīng)，但是應(yīng)用服務(wù)器可能并不是很繁忙，cpu利用率也非常低，引起這種狀況的原因有很多種，比如環(huán)境問題，應(yīng)用資源泄漏，數(shù)據(jù)庫原因等等，本文主要是從一次應(yīng)用性能診斷過程來談?wù)勅绾瓮ㄟ^數(shù)據(jù)庫診斷應(yīng)用性能問題。
問題：
測試過程中發(fā)現(xiàn)應(yīng)用中某個(gè)跳轉(zhuǎn)頁面執(zhí)行時(shí)間比較長，系統(tǒng)壓力不大，cpu利用很低，該頁面需要從cache中取數(shù)據(jù)，第一次的時(shí)候加載cache（從數(shù)據(jù)庫中查詢回?cái)?shù)據(jù)并cache）。
診斷：
頁面邏輯比較簡單，我們先用loadrunner模擬并發(fā)測試一下這個(gè)頁面，然后再數(shù)據(jù)庫端捕獲sql執(zhí)行情況。
1、打開db2監(jiān)控開關(guān)
#db2 connect to eos
#db2 update monitor switches using statement on
#db2 reset monitor all
2、幾分鐘之后，我們收集sql統(tǒng)計(jì)快照
#db2 get snapshot for dynamic sql on eos > dysqlstatus.out
現(xiàn)在統(tǒng)計(jì)信息已經(jīng)存放在dysqlstatus.out中，你可以使用任意方便的文本處理工具查看，我一般用windows上的gvim來處理，打開dysqlstatus.out
Number of executions = 1
Number of compilations = 1
Worst preparation time (ms) = 2
Best preparation time (ms) = 2
Internal rows deleted = 0
Internal rows inserted = 0
Rows read = 2
Internal rows updated = 0
Rows written = 0
Statement sorts = 0
Statement sort overflows = 0
Total sort time = 0
Buffer pool data logical reads = Not Collected
Buffer pool data physical reads = Not Collected
Buffer pool temporary data logical reads = Not Collected
Buffer pool temporary data physical reads = Not Collected
Buffer pool index logical reads = Not Collected
Buffer pool index physical reads = Not Collected
Buffer pool temporary index logical reads = Not Collected
Buffer pool temporary index physical reads = Not Collected
Total execution time (sec.ms) = 0.000377
Total user cpu time (sec.ms) = 0.010000
Total system cpu time (sec.ms) = 0.000000
Statement text = select ACTIVITYDEFID,ACTIVITYINSTID from wfworkitem where
PROCESSINSTID=104199 and CURRENTSTATE = 4
......
簡單說一下vi中的處理
:g!/Total execution time/d
只保留文本中的sql執(zhí)行時(shí)間，我們要按照執(zhí)行時(shí)間來排序
通過vim的visual功能選擇執(zhí)行時(shí)間塊（等號(hào)后面的數(shù)字），然后排序
Total execution time (sec.ms) = 0.050590
Total execution time (sec.ms) = 0.000170
Total execution time (sec.ms) = 0.000247
Total execution time (sec.ms) = 0.000292
Total execution time (sec.ms) = 0.000474
Total execution time (sec.ms) = 0.000330
Total execution time (sec.ms) = 0.000348
Total execution time (sec.ms) = 0.000279
Total execution time (sec.ms) = 0.000385
Total execution time (sec.ms) = 0.000296
Total execution time (sec.ms) = 0.000261
Total execution time (sec.ms) = 0.000195
Total execution time (sec.ms) = 0.000226
Total execution time (sec.ms) = 0.000227
Total execution time (sec.ms) = 0.000193
......
:'<,'>!sort
排序后的結(jié)果（部分）
Total execution time (sec.ms) = 2.027776
Total execution time (sec.ms) = 2.203624
Total execution time (sec.ms) = 2.504677
Total execution time (sec.ms) = 2.951256
Total execution time (sec.ms) = 3.119875
Total execution time (sec.ms) = 3.303277
Total execution time (sec.ms) = 3.303517
Total execution time (sec.ms) = 4.017133
Total execution time (sec.ms) = 4.043329
Total execution time (sec.ms) = 4.252125
Total execution time (sec.ms) = 4.400952
Total execution time (sec.ms) = 4.606765
Total execution time (sec.ms) = 5.208087
Total execution time (sec.ms) = 5.778598
Total execution time (sec.ms) = 8.117470
Total execution time (sec.ms) = 9797.905136
可以看到最長時(shí)間的sql total執(zhí)行時(shí)間耗費(fèi)了3797.905123s.
現(xiàn)在我們到dysqlstatus.out中去找這條語句
Number of executions = 4602
Number of compilations = 4294967295
Worst preparation time (ms) = 2
Best preparation time (ms) = 2
Internal rows deleted = 0
Internal rows inserted = 0
Rows read = 2963688
Internal rows updated = 0
Rows written = 0
Statement sorts = 0
Statement sort overflows = 0
Total sort time = 0
Buffer pool data logical reads = Not Collected
Buffer pool data physical reads = Not Collected
Buffer pool temporary data logical reads = Not Collected
Buffer pool temporary data physical reads = Not Collected
Buffer pool index logical reads = Not Collected
Buffer pool index physical reads = Not Collected
Buffer pool temporary index logical reads = Not Collected
Buffer pool temporary index physical reads = Not Collected
Total execution time (sec.ms) = 9797.905136
Total user cpu time (sec.ms) = 9.290000
Total system cpu time (sec.ms) = 1.230000
Statement text = select * from XXXX_T_CNFACTIVITYDEF
這條語句總共執(zhí)行了4602次，平均每次的執(zhí)行時(shí)間2S，而且這些數(shù)據(jù)應(yīng)該是被cache起來的 ；）
總結(jié)：
上面的方法簡單總結(jié)了從數(shù)據(jù)庫層面對應(yīng)用的性能問題診斷，希望對大家有所幫助，對于數(shù)據(jù)庫快照診斷問題的思路對于任意數(shù)據(jù)庫通用
補(bǔ)充一個(gè)unix上腳本處理方式：
sqlsort.sh
awk 'BEGIN{RS="";FS="\n";ORS="\n"};/Statement text/{print $1, $21, $24}' $1 | awk '$5 > 0 {print "AvgTime:", $11/$5, "\t", $0}'| sort -n | head -n $2|awk '{print $0, "\n"}'
使用：#sqlsort.sh dysqlstate.out 10（顯示Top ten）
作者：tacy lee
在應(yīng)用中，我們經(jīng)常會(huì)碰到sql執(zhí)行很慢，但是數(shù)據(jù)庫cpu和內(nèi)存使用率又不高的情況，類似的問題基本上由于鎖，排序等原因造成，本文主要描述如何去定位鎖等待問題，誰在鎖等待？等待誰持有的鎖？鎖在那個(gè)表？
一、測試準(zhǔn)備
1、先在session1執(zhí)行如下操作，創(chuàng)建測試表
#db2 connect to eos
#export DB2OPTIONS=+C
#db2 "create table tacy_test (a int not null primary key,b varchar(10))"
#db2 "insert into tacy_test values(1,'a')"
#db2 "insert into tacy_test values(2,'a')"
#db2 "insert into tacy_test values(3,'a')"
#db2 "insert into tacy_test values(4,'a')"
#db2 commit
2、在session2執(zhí)行如下操作
#db2 connect to eos
#export DB2OPTIONS=+C
二、產(chǎn)生一個(gè)lock wait
在session1做一個(gè)表更新：
#db2 "update tacy_test set b='b' where a=4"
sql執(zhí)行成功
在session2做同樣更新操作：
#db2 "update tacy_test set b='c' where a=4"
進(jìn)程被掛起等待
三、定位鎖等待
1、先來看看應(yīng)用的情況：
#db2pd -db eos -applications
Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:37:37
Applications:
Address AppHandl [nod-index] NumAgents CoorPid Status C-AnchID C-StmtUID L-AnchID L-StmtUID Appid
0x10140040 8 [000-00008] 1 8425 Lock-wait 80 2 66 1 *LOCAL.db2inst1.071124043739
0x100CE540 7 [000-00007] 1 8358 UOW-Waiting 0 0 80 2 *LOCAL.db2inst1.071124043708
可以看到有一個(gè)應(yīng)用的狀態(tài)處于Lock-wait
2、現(xiàn)在我們來看看應(yīng)用在等什么
#db2pd -db eos -locks showlock wait
Database Partition 0 -- Database EOS -- Active -- Up 0 days 07:42:56
Locks:
Address TranHdl Lockname Type Mode Sts Owner Dur HldCnt Att Rlse
0x2C8E0760 3 02001806078066020000000052 Row ..X W 2 1 0 0 0x0 TbspaceID 2 TableID 1560 RecordID 0x2668007
鎖的類型為Row（行鎖），X鎖（排他鎖），下面是我們最關(guān)心的鎖的位置
TbspaceID 2 TableID 1560 RecordID 0x2668007
其中TbspaceID為表空間ID，TableID為表的ID，RecordID代表具體位置，全部應(yīng)該是0x0266807,其中前面三個(gè)字節(jié)為page number，為0x02668，后面一個(gè)字節(jié)代表solt identifier，為0x07
3、找到相應(yīng)的表
#db2 "select tbspace,tabschema,tabname,tableid,tbspaceid from syscat.tables where tbspaceid=2 and tableid=1560"
TBSPACE TABSCHEMA TABNAME TABLEID TBSPACEID
------------ ----------- ---------- ------- ---------
USERSPACE1 DB2INST1 TACY_TEST 1560 2
1 record(s) selected.
4、根據(jù)RecordID找到鎖在哪行
db2提供了一個(gè)強(qiáng)大的數(shù)據(jù)分析工具db2dart，可以dump出相應(yīng)的page數(shù)據(jù)
#db2dart eos /dd /tsi 2 /oi 1560 /ps 157312p /np 1 /v y
Warning: The database state is not consistent.
Warning: Reorg rows MAY be due to the inconsistent state of the database.
DB2DART Processing completed with warning(s)!
Complete DB2DART report found in:
/home/db2inst1/sqllib/db2dump/DART0000/EOS.RPT其中tsi為表空間id(2)，oi為表id(1560)，ps為page number(0x0266807)，需要轉(zhuǎn)換為十進(jìn)制，在結(jié)尾必須加p，np代表你要獲取的頁數(shù)，v為是否詳細(xì)輸出
現(xiàn)在我們來看看EOS.RPT
______________________________________________________________________________
_______ DART _______
D a t a b a s e A n a l y s i s a n d R e p o r t i n g T o o l
IBM DB2 6000
______________________________________________________________________________
DART (V8.1.0) Report:
2007-11-24-20.59.51.355893
Database Name: EOS
Report name: EOS.RPT
Old report back-up: EOS.BAK
Database Subdirectory: /opt/db2/db2inst1/NODE0000/SQL00001
Operational Mode: Database Inspection Only (INSPECT)
______________________________________________________________________________
------------------------------------------------------------------------------
Action option: DD
Table-object-ID: 1560; Tablespace-ID: 2; First-page: 157312p; Number-pages: 1; Verbose: y
Warning: The database state is not consistent.
Warning: Reorg rows MAY be due to the inconsistent state of the database.
Connecting to Buffer Pool Services...
Table object report phase start.
Dump format is verbose.
______________________________________
Page 0 of object 1560 from table space 2.
BPS Page Header:
Page Data Offset = 48
Page Data Length = 4048
Page LSN = 0000 AE97 AE41
Object Page Number = 0
Pool Page Number = 157312
Object ID = 1560
Object Type = Data Object
Data Page Header:
Slot Count = 8
Total Free Space = 2784
Total Reserve Space = 0
Youngest Reserve Space = n/a
Youngest TID = n/a
Free Space Offset = 2799
Maximum Record Size = 23
Data Records:
Slot 0:
Offset Location = 3996 (xF9C)
Record Length = 32 (x20)
Record Type = Data Object Header Control Record
Page count = 1
Object Creation LSN = 0000 AE97 800C
Object State = x0000
UDI Since Runstats = 0
DART Field = x00000000
Slot 1:
Offset Location = 2992 (xBB0)
Record Length = 1004 (x3EC)
Record Type = Free Space Control Record
Free space entries:
0: 2884 (x0B44), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC)
4: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC)
8: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC)
省略。。。
492: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC)
496: 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC), 4028 (x0FBC)
Slot 2:
Offset Location = 2916 (xB64)
Record Length = 76 (x4C)
Record Type = Table Directory Record
MetaIndex Root Page = 157377
Index Type = 2
Table Descriptor Pointer -- Page 157312 Slot 3
Max Insert Search = 0
Flags = x02000200
bit representation = 00000010 00000000 00000010 00000000
Check pending info:
Constraint status = x00
Constraint RID = Page 0 Slot 0
last BID = x00000000
Slot 3:
Offset Location = 2892 (xB4C)
Record Length = 24 (x18)
Record Type = Table Description Record
Number of Columns = 2
Column 1:
Type is Long Integer
Length = 4
Prohibits NULLs
Prohibits Default
Fixed offset: 0
Column 2:
Type is Fixed Length Character String
Length = 10
Allows NULLs
Prohibits Default
Fixed offset: 4
Slot 4:
Offset Location = 2869 (xB35)
Record Length = 23 (x17)
Record Type = Table Data Record (FIXEDVAR)
Fixed part length value = 15
Column 1:
Fixed offset: 0
Type is Long Integer
Value = 1
Column 2:
Fixed offset: 4
Type is Fixed Length Character String
61202020 20202020 2020 a
Slot 5:
Offset Location = 2846 (xB1E)
Record Length = 23 (x17)
Record Type = Table Data Record (FIXEDVAR)
Fixed part length value = 15
Column 1:
Fixed offset: 0
Type is Long Integer
Value = 2
Column 2:
Fixed offset: 4
Type is Fixed Length Character String
61202020 20202020 2020 a
Slot 6:
Offset Location = 2823 (xB07)
Record Length = 23 (x17)
Record Type = Table Data Record (FIXEDVAR)
Fixed part length value = 15
Column 1:
Fixed offset: 0
Type is Long Integer
Value = 3
Column 2:
Fixed offset: 4
Type is Fixed Length Character String
61202020 20202020 2020 a
Slot 7:
Offset Location = 2800 (xAF0)
Record Length = 23 (x17)
Record Type = Table Data Record (FIXEDVAR)
Fixed part length value = 15
Column 1:
Fixed offset: 0
Type is Long Integer
Value = 4
Column 2:
Fixed offset: 4
Type is Fixed Length Character String
61202020 20202020 2020 a
Slots Summary: Total=8, In-use=8, Deleted=0.
Table object report phase end.
______________________________________
DB2DART Processing completed with warning(s)!
Warning(s) detected during processing.
______________________________________
Complete DB2DART report found in:
/home/db2inst1/sqllib/db2dump/DART0000/EOS.RPT
_______ D A R T P R O C E S S I N G C O M P L E T E _______找到Solt 7 (0x07)，ok，你現(xiàn)在可以清楚的知道應(yīng)用等待的Row為(4,a)
總結(jié)
通過上面的方法，我們簡單描述了一個(gè)db2鎖問題的定位方法，希望能給大家在分析和定位應(yīng)用性能問題的時(shí)候起到一定的幫助
作者：tacy lee
一：基本介紹
在Loadrunner的使用中，對于Run-time Settings下的browser emulation設(shè)置是比較容易讓人產(chǎn)生困惑的地方。下面我們結(jié)合sniffer來具體看看每個(gè)選項(xiàng)的用途，以及對測試的影響。
Browser Emulation 圖
二：案例和工具
1. 測試案例：
打開網(wǎng)站首頁兩次，對比不同Browser Emulation設(shè)置下loadrunner的行為，腳本如下。
Action()
{
web_url("www.primeton.com",
"URL=http://www.primeton.com/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t2.inf",
"Mode=HTML",
LAST);
web_url("www.primeton.com",
"URL=http://www.primeton.com/",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t2.inf",
"Mode=HTML",
LAST);
return 0;
}
2. sniffer工具
開源工具：Wireshark(前身是ethereal)（www.wireshark.org）
三：測試過程
為了方便描述，我們約定用：
A代表Simulate browser cache
B代表Cache URLs requiring content(HTMLs)
C代表Check for newer versions of stored pages every visit to the page
D代表Download non-HTML resources
E代表Simulate a new user on each iteratioin
F代表Clear cache on each iteration
首先設(shè)置Run Logic中的iteration為2。讓Action運(yùn)行兩次，看看循環(huán)運(yùn)行腳本兩次，數(shù)據(jù)包和連接數(shù)的變化。
1. 去掉所有選項(xiàng)
結(jié)果：共獲取數(shù)據(jù)包95個(gè)，建立連接1個(gè)（紅色標(biāo)識(shí)），斷開連接1個(gè)（藍(lán)色標(biāo)識(shí)）
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.61 203.81.29.137 TCP 13835 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
2 0.036053 203.81.29.137 192.168.1.61 TCP http > 13835 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
92 1.415887 192.168.1.61 203.81.29.137 TCP 13835 > http [FIN, ACK] Seq=817 Ack=71762 Win=257760 Len=0
94 1.449960 203.81.29.137 192.168.1.61 TCP http > 13835 [FIN, ACK] Seq=71762 Ack=818 Win=16464 Len=0
在這種情況下，數(shù)據(jù)包非常少（沒有選擇下載資源文件入css,js,gif等），而且你可以看到，打開4次首頁，只建立了一個(gè)tcp連接。
這時(shí)，你即使選擇A，發(fā)現(xiàn)數(shù)據(jù)包的數(shù)量量頁沒有變化，因?yàn)閏ache主要還是針對資源文件
2. 選擇E(F)
結(jié)果：共獲取數(shù)據(jù)包102個(gè)，建立連接2個(gè)（紅色標(biāo)識(shí)），斷開連接2個(gè)（藍(lán)色標(biāo)識(shí)）
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.61 203.81.29.137 TCP 13886 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
2 0.037013 203.81.29.137 192.168.1.61 TCP http > 13886 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
48 0.618117 192.168.1.61 203.81.29.137 TCP 13886 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
49 0.644106 192.168.1.61 203.81.29.137 TCP 13887 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
51 0.651919 203.81.29.137 192.168.1.61 TCP http > 13886 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
53 0.676377 203.81.29.137 192.168.1.61 TCP http > 13887 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
99 1.310379 192.168.1.61 203.81.29.137 TCP 13887 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
101 1.347949 203.81.29.137 192.168.1.61 TCP http > 13887 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
在這種情況下，數(shù)據(jù)包非常少（沒有選擇下載資源文件入css,js,gif等），對比第一種情況，你會(huì)發(fā)現(xiàn)它建立了兩個(gè)連接，這就是E的作用，它對于每次迭代都當(dāng)成一個(gè)新的用戶，需要重新建立連接。
3. 選擇DE(F)
結(jié)果：共獲取數(shù)據(jù)包1782個(gè)，建立連接6個(gè)（紅色標(biāo)識(shí)），斷開連接6個(gè)（藍(lán)色標(biāo)識(shí)）
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.61 203.81.29.137 TCP 14016 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
2 0.037911 203.81.29.137 192.168.1.61 TCP http > 14016 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
6 0.107432 192.168.1.61 203.81.29.137 TCP 14017 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
9 0.141816 203.81.29.137 192.168.1.61 TCP http > 14017 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
426 3.334889 192.168.1.61 203.81.29.137 TCP 14017 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
428 3.372253 203.81.29.137 192.168.1.61 TCP http > 14017 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
448 4.395488 192.168.1.61 203.81.29.137 TCP 14020 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
457 4.439604 203.81.29.137 192.168.1.61 TCP http > 14020 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
859 7.593610 192.168.1.61 203.81.29.137 TCP 14016 > http [FIN, ACK] Seq=2849 Ack=377404 Win=257484 Len=0
870 7.659680 203.81.29.137 192.168.1.61 TCP http > 14016 [FIN, ACK] Seq=377404 Ack=2850 Win=15935 Len=0
888 8.511308 192.168.1.61 203.81.29.137 TCP 14020 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0
890 8.549451 203.81.29.137 192.168.1.61 TCP http > 14020 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0
892 8.566246 192.168.1.61 203.81.29.137 TCP 14022 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
893 8.601893 203.81.29.137 192.168.1.61 TCP http > 14022 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
899 8.702628 192.168.1.61 203.81.29.137 TCP 14023 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
904 8.741807 203.81.29.137 192.168.1.61 TCP http > 14023 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
1298 11.809456 192.168.1.61 203.81.29.137 TCP 14022 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0
1310 11.878665 203.81.29.137 192.168.1.61 TCP http > 14022 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0
1341 12.771707 192.168.1.61 203.81.29.137 TCP 14026 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
1348 12.813950 203.81.29.137 192.168.1.61 TCP http > 14026 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
1759 16.032952 192.168.1.61 203.81.29.137 TCP 14023 > http [FIN, ACK] Seq=3151 Ack=367918 Win=257484 Len=0
1761 16.068296 203.81.29.137 192.168.1.61 TCP http > 14023 [FIN, ACK] Seq=367918 Ack=3152 Win=17280 Len=0
1779 16.983042 192.168.1.61 203.81.29.137 TCP 14026 > http [FIN, ACK] Seq=1602 Ack=208150 Win=257760 Len=0
1781 17.016836 203.81.29.137 192.168.1.61 TCP http > 14026 [FIN, ACK] Seq=208150 Ack=1603 Win=17280 Len=0
在這種情況下，數(shù)據(jù)包的數(shù)量非常大，連接也很多，由于沒有cache功能，每次打開頁面都需要重新下載所有的資源文件。
4. 選擇ADE
結(jié)果：共獲取數(shù)據(jù)包525個(gè)，建立連接3個(gè)，斷開連接3個(gè)(不再標(biāo)識(shí)了，syn即為連接請求，fin即為斷開請求）
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.61 203.81.29.137 TCP 14189 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
2 0.033657 203.81.29.137 192.168.1.61 TCP http > 14189 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
6 0.100636 192.168.1.61 203.81.29.137 TCP 14190 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
9 0.133703 203.81.29.137 192.168.1.61 TCP http > 14190 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
429 3.383748 192.168.1.61 203.81.29.137 TCP 14190 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
431 3.418556 203.81.29.137 192.168.1.61 TCP http > 14190 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
471 4.352071 192.168.1.61 203.81.29.137 TCP 14189 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0
472 4.380312 192.168.1.61 203.81.29.137 TCP 14192 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
474 4.389778 203.81.29.137 192.168.1.61 TCP http > 14189 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0
476 4.413220 203.81.29.137 192.168.1.61 TCP http > 14192 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
522 5.078068 192.168.1.61 203.81.29.137 TCP 14192 > http [FIN, ACK] Seq=409 Ack=35882 Win=257760 Len=0
524 5.115099 203.81.29.137 192.168.1.61 TCP http > 14192 [FIN, ACK] Seq=35882 Ack=410 Win=16872 Len=0
在這種情況下，cache發(fā)揮作用，數(shù)據(jù)包對比第三種情況大大減少，幾乎等于打開一次首頁的數(shù)據(jù)量（449個(gè)數(shù)據(jù)包），只有第一次打開頁面需要完整下載頁面（包括資源文件），后面的三次打開頁面都只要下載HTML頁面（不包括資源文件）。
5. 選擇ADEF
選擇F之后我們看看結(jié)果：共獲取數(shù)據(jù)包942個(gè)，建立連接4個(gè)，斷開連接4個(gè)
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.61 203.81.29.137 TCP 14292 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
2 0.034524 203.81.29.137 192.168.1.61 TCP http > 14292 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
6 0.102314 192.168.1.61 203.81.29.137 TCP 14294 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
9 0.139752 203.81.29.137 192.168.1.61 TCP http > 14294 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
426 3.791111 192.168.1.61 203.81.29.137 TCP 14294 > http [FIN, ACK] Seq=1852 Ack=150284 Win=257484 Len=0
428 3.824970 203.81.29.137 192.168.1.61 TCP http > 14294 [FIN, ACK] Seq=150284 Ack=1853 Win=16998 Len=0
468 6.213276 192.168.1.61 203.81.29.137 TCP 14292 > http [FIN, ACK] Seq=1504 Ack=235576 Win=257760 Len=0
469 6.244052 192.168.1.61 203.81.29.137 TCP 14297 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
471 6.249564 203.81.29.137 192.168.1.61 TCP http > 14292 [FIN, ACK] Seq=235576 Ack=1505 Win=17280 Len=0
473 6.279647 203.81.29.137 192.168.1.61 TCP http > 14297 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
479 6.374967 192.168.1.61 203.81.29.137 TCP 14298 > http [SYN] Seq=0 Len=0 MSS=1460 WS=2
484 6.419597 203.81.29.137 192.168.1.61 TCP http > 14298 [SYN, ACK] Seq=0 Ack=1 Win=17280 Len=0 MSS=1440 WS=0
897 9.858493 192.168.1.61 203.81.29.137 TCP 14297 > http [FIN, ACK] Seq=1550 Ack=159770 Win=257484 Len=0
899 9.895188 203.81.29.137 192.168.1.61 TCP http > 14297 [FIN, ACK] Seq=159770 Ack=1551 Win=17280 Len=0
939 12.840029 192.168.1.61 203.81.29.137 TCP 14298 > http [FIN, ACK] Seq=1806 Ack=226090 Win=257760 Len=0
941 12.876120 203.81.29.137 192.168.1.61 TCP http > 14298 [FIN, ACK] Seq=226090 Ack=1807 Win=17076 Len=0
在這種情況下，由于選擇了F，在迭代的時(shí)候清除了cache，所以每次迭代都需要重新下載資源文件。數(shù)據(jù)包差不多等于第三種情況的一半，約等于打開兩次首頁的數(shù)據(jù)量（449×2個(gè)數(shù)據(jù)包）。
6. 關(guān)于BC選項(xiàng)
C的解釋（Check for newer versions of stored pages every visit to the page）
C比較容易理解，類似IE設(shè)置中的每次檢查，如果不設(shè)置C，LR對于已經(jīng)cache的文件就不會(huì)重新向服務(wù)器請求，如果選擇C，你就可以在數(shù)據(jù)包中發(fā)現(xiàn)很多304信息。
B的解釋（Cache URLs requiring content(HTMLs)）
LR對于資源文件的cache并不會(huì)真正cache在內(nèi)存中或者在磁盤上，這個(gè)選項(xiàng)表示：對于一些需要用到的關(guān)聯(lián)，校驗(yàn)，頁面解析內(nèi)容真正cache在內(nèi)存中，減少客戶端的重復(fù)工作。
當(dāng)然如果你想把GIF也cache到內(nèi)存中，你可以在Advanced中設(shè)置，選擇Specify URL requiring content in addition to HTML pages，加入條目image/gif，并勾選。當(dāng)Vuser運(yùn)行的時(shí)候，你可以對比一下mmdrv.exe進(jìn)程的內(nèi)存消耗（內(nèi)存占用會(huì)更多）。
四： 結(jié)論
通過上面的測試分析，我們大概知道了每個(gè)選項(xiàng)的真正含義，你需要根據(jù)你的測試目的來選擇合適的設(shè)置：
1、 對于一個(gè)具體的應(yīng)用測試，對于前端Web Server不可忽略，缺省設(shè)置非常合適，不需要調(diào)整（有時(shí)候需要考慮把C選上）
注意：很多人在錄制腳本的時(shí)候，習(xí)慣把登入操作放到vuser_init中，這時(shí)候缺省設(shè)置可能會(huì)拋錯(cuò)，建議把這類的操作都放入到action中
2、 如果你更關(guān)注后端應(yīng)用服務(wù)器的性能或者說做一些架構(gòu)的驗(yàn)證分析，那你缺省設(shè)置對于你來說就不合適了，你需要選擇取消所有的設(shè)置項(xiàng)。
當(dāng)然你也可以根據(jù)自己的具體情況做不同調(diào)整，但是一定要真正理解這些選項(xiàng)的具體含義才能做到不犯錯(cuò)誤
編譯的時(shí)候出現(xiàn)java拋如下異常：
java.nio.BufferOverflowException
at java.nio.Buffer.nextPutIndex(Buffer.java:419)
at java.nio.HeapCharBuffer.put(HeapCharBuffer.java:145)
at com.sun.tools.javac.parser.Scanner.decode(Scanner.java:405)
at com.sun.tools.javac.parser.Scanner.<init>(Scanner.java:304)
at com.sun.tools.javac.parser.Scanner.<init>(Scanner.java:238)
at com.sun.tools.javac.parser.Scanner$Factory.newScanner(Scanner.java:72)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:254)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:281)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:399)
at com.sun.tools.javac.main.Main.compile(Main.java:592)
at com.sun.tools.javac.main.Main.compile(Main.java:544)
at com.sun.tools.javac.Main.compile(Main.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:55)
at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:936)
at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeTarget(Project.java:1214)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.startAnt(BizletProcessor.java:327)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.prepareclass(BizletProcessor.java:419)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.init(BizletProcessor.java:374)
at com.primeton.studio.compile.java.bizlets.BizletProcessor.build(BizletProcessor.java:130)
at com.primeton.studio.compile.frame.ProjectProcessor.buildBizlets(ProjectProcessor.java:161)
at com.primeton.studio.compile.frame.ProjectProcessor.build(ProjectProcessor.java:115)
at com.primeton.studio.compile.frame.SimpleBuilder.build(SimpleBuilder.java:195)
at com.primeton.studio.compile.frame.SimpleBuilder.build(SimpleBuilder.java:182)
at com.primeton.studio.compile.frame.SimpleBuilder.main(SimpleBuilder.java:265)
查了一下，估計(jì)是java采用gbk字符集（缺省windows的中文字符集），導(dǎo)致stack區(qū)溢出（明顯沒對國際化測試不足嘛）
解決問題的方法就是修改系統(tǒng)的缺省區(qū)域設(shè)置為English既可。
del.icio.us Tags:
java ,
ant ,
build ,
tips
故障現(xiàn)象：
測試一段時(shí)間后應(yīng)用無響應(yīng)，連接池不能放大，jvm crash，日志報(bào)對象分配失敗
問題診斷：
第一個(gè)階段是websphere問題
到現(xiàn)場之后，回放腳本測試幾分鐘，應(yīng)用開始無法響應(yīng)，后臺(tái)也沒有異常，update jdk之后，系統(tǒng)能正常響應(yīng)了，但是發(fā)現(xiàn)新的問題，db2連接池始終無法放大，最大只能到30，而且系統(tǒng)也會(huì)拋OOM，導(dǎo)致系統(tǒng)異常推出，從系統(tǒng)日志看，是因?yàn)閼?yīng)用中的大對象分配導(dǎo)致的（2M大小）
期間，關(guān)于連接池?zé)o法放大問題想了很多辦法，包括修改db2 maxappls,maxagents這些參數(shù)，更新數(shù)據(jù)庫驅(qū)動(dòng)，而且確定不是db2的問題（在創(chuàng)建30之后，我們依然可以通過其他方式連接到db2，說明db2的連接限制確實(shí)放大了），當(dāng)然我們productdatasource這個(gè)池子大小我已經(jīng)放大到100了。
中間還發(fā)現(xiàn)測試腳本沒有正常啟動(dòng)流程，排查后發(fā)現(xiàn)是loadrunner的問題，用我機(jī)器上的lr錄制正常（錯(cuò)誤代碼提示是字段長度限制，莫名其妙）。
關(guān)于jvm crach我們也調(diào)整了heap設(shè)置：-xms256m,-xmx1536m
但是問題依然存在。后面我們重新安裝了應(yīng)用，所有的設(shè)置采用缺省配置，沒有打任何補(bǔ)丁，系統(tǒng)這個(gè)時(shí)候竟然可以正常跑了，只是響應(yīng)很慢，而且時(shí)間曲線一直往上拋（測試一段時(shí)間系統(tǒng)無響應(yīng)）
查了一下配置，發(fā)現(xiàn)productdatasource的缺省設(shè)置竟然就是30，這個(gè)時(shí)候基本判斷是之前的websphere的設(shè)置修改沒有生效
重新修改jvm和連接池配置，這時(shí)候系統(tǒng)正常，數(shù)據(jù)連接也達(dá)到83個(gè)，然后開始測試大并發(fā)量
階段二就是調(diào)整數(shù)據(jù)庫配置
1、第一個(gè)是db2 default buffer pool，缺省配置buffer才4m，這個(gè)一定要注意修改
2、第二個(gè)是db2的lock數(shù)量，在缺省基礎(chǔ)上好像放大了100倍
3、sort heap，排序區(qū)（防止排序溢出）
這些調(diào)整都要通過db2的狀態(tài)來調(diào)整，可以通過get snapshot指令來獲得數(shù)據(jù)庫狀態(tài)，buffer不夠會(huì)出現(xiàn)大量的邏輯讀，lock不夠會(huì)拋lock溢出(會(huì)導(dǎo)致鎖升級(jí)），sort heap不夠會(huì)提示排序溢出（這時(shí)候排序會(huì)在硬盤做）
回頭看看這次支持：
1、websphere配置修改不生效，我后面仔細(xì)想了想，這個(gè)websphere很多公司用可能大家都亂改了一通，另一問題是我們的使用習(xí)慣，websphere強(qiáng)烈不建議用kill直接殺進(jìn)程方式停服務(wù)器，websphere不但是一個(gè)java進(jìn)程，還有很多的附屬進(jìn)程，直接kill也很容易導(dǎo)致websphere不正常
2、jvm crach問題，這個(gè)我建議大家看看這篇文檔http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=fragmentation
&uid=swg21176363&loc=en_US&cs=utf-8&lang=en
如何去定位jvm問題，首先看nativerr.log日志，如果出現(xiàn)OOM，這里會(huì)有記錄，當(dāng)發(fā)現(xiàn)OOM的時(shí)候，可以打開jvm的verbosegc，分析verbosegc和jvm dump file，上面文檔里提到一個(gè)很重要的東西就是pinned對象，這也是ibm為啥不建議設(shè)置ms=mx的原因。
先建立一個(gè)監(jiān)控器
db2 "create event monitor SQLCOST for statements write to file '/home/db2inst1'"
再設(shè)置事務(wù)狀態(tài)為打開
db2 "set event monitor SQLCOST state=1"
注：1為打開，0為關(guān)閉，收集數(shù)據(jù)之后，記得關(guān)閉你的監(jiān)控器，否則。。。
跑你的測試后，在你的/home/db2inst1目錄下會(huì)生成一些evm文件
用下面指令獲取診斷信息：
db2evmon -db eos51 -evm SQLCOST>sqlcost1.txt
完成之后刪除你的監(jiān)控器
db2 "drop event monitor SQLCOST"
生成的采樣例子，從下面的例子中，你可以清除的看到SQL執(zhí)行的時(shí)間，CPU消耗情況，排序是否溢出，BufferPool的使用情況，根據(jù)這些信息，SQL的執(zhí)行效率一目了然：
26) Statement Event ...
Appl Handle: 336
Appl Id: C0A80421.O905.0ABDA5065446
Appl Seq number: 0657
Record is the result of a flush: FALSE
-------------------------------------------
Type : Dynamic
Operation: Execute
Section : 7
Creator : NULLID
Package : SYSSN300
Consistency Token : SYSLVL01
Package Version ID :
Cursor : SQL_CURSN300C7
Cursor was blocking: FALSE
Text : update WFProcessInst set relateData=? where processInstID= ?
-------------------------------------------
Start Time: 04/25/2007 14:57:19.402248
Stop Time: 04/25/2007 14:57:19.409622
Exec Time: 0.007374 seconds
Number of Agents created: 1
User CPU: 0.000000 seconds
System CPU: 0.000000 seconds [licl1]
Fetch Count: 0
Sorts: 0
Total sort time: 0
Sort overflows: 0 [licl2]
Rows read: 1
Rows written: 1
Internal rows deleted: 0
Internal rows updated: 0
Internal rows inserted: 0
Bufferpool data logical reads: 9
Bufferpool data physical reads: 0
Bufferpool temporary data logical reads: 0
Bufferpool temporary data physical reads: 0
Bufferpool index logical reads: 3
Bufferpool index physical reads: 0
Bufferpool temporary index logical reads: 0
Bufferpool temporary index physical reads: 0 [licl3]
SQLCA:
sqlcode: 0
sqlstate: 00000
[licl1]SQL執(zhí)行時(shí)間和CPU消耗情況
[licl2]SQL的排序情況，可以看到這個(gè)SQL沒有排序，當(dāng)然也沒有排序溢出
[licl3]Bufferpool的使用情況，邏輯讀和物理讀的對比
del.icio.us Tags:
database ,
db2 ,
tuning
作者：tacy lee
簡單介紹一下Loadrunner Analysis中的Web Page Diagnostics模塊的使用，很多人對于測試之后的結(jié)果數(shù)據(jù)分析摸不著頭腦，其實(shí)loadrunner Analysis給你提供了很好的文檔，大家沒事可以多翻翻，多翻幾遍對于性能測試你就入門了 ；）
Web Page Diagnostics （以下簡稱WPD），這是LR Analysis中非常重要的一塊，搞清楚這部分的內(nèi)容會(huì)讓你少走很多彎路，很多環(huán)境問題都可以通過它來定位，比如客戶端，網(wǎng)絡(luò)。通過它可以你可以比較好的來定位是環(huán)境的問題還是應(yīng)用本身的問題，當(dāng)然更重要的是Web頁面本身的問題。
WPD包括下面幾個(gè)圖表：
Web Page Diagnostics 這是張總圖，包括下面幾張Over Time圖的內(nèi)容
Page Component Breakdown 頁面中每個(gè)元素的平均響應(yīng)時(shí)間占整個(gè)頁面響應(yīng)時(shí)間的百分比
Page Component Breakdown(Over Time) 在整個(gè)測試過程中，任意一秒內(nèi)頁面中每個(gè)元素的響應(yīng)時(shí)間（例如在runtime中設(shè)置了browser cache，頁面中的資源文件就只會(huì)在第一次下載，后面的頁面響應(yīng)時(shí)間也就不包括這些元素的時(shí)間，這在Page Component Breakdown中是看不出來的，因?yàn)镻age Component Breakdown是整個(gè)測試期間內(nèi)的平均時(shí)間。當(dāng)然，是否啟用了cache，通過over time圖就能看出來）
Page Download Time Breakdown 頁面中每個(gè)元素的響應(yīng)時(shí)間分割圖，響應(yīng)時(shí)間被分割為以下幾個(gè)部分：DNS Resolution,Connection,First Buffer,SSL Handshaking,Receive,FTP Authentication,Client,Error
Page Download Time Breakdown(Over Time) 在整個(gè)測試過程中，任意一秒內(nèi)頁面中每個(gè)元素的響應(yīng)時(shí)間分割圖
Time to First Buffer Breakdown First Buffer Time時(shí)間分割為Network Time和Server Time，客戶端http請求發(fā)送到接收到服務(wù)器端的應(yīng)答包（ACK）為Network Time，從接收到ACK到完成First Buffer接受為Server Time
Time to First Buffer Breakdown(Over Time) 基本同上，任意一秒內(nèi)的
Downloaded Component Size(KB) 頁面中每個(gè)元素的大小（KB）
介紹了這么多，具體如何分析呢？
首先打開Web Page Diagnostics圖，來看看下面一個(gè)例子Download Time圖：
上圖存在兩個(gè)問題：
1、receive時(shí)間很長
這個(gè)一般是網(wǎng)絡(luò)問題，當(dāng)然如果你確認(rèn)網(wǎng)絡(luò)不存在問題，那么你就要看看是不是客戶端的問題（客戶端也可能會(huì)造成Receive過長，這個(gè)千萬要注意）
2、頁面問題
頁面上包括了非常多的圖片，而且圖片似乎都沒有優(yōu)化，最大的竟然有163K，記下來，這可是罪證哦 ；）
很多時(shí)候，你可以根據(jù)DNS,Connection,Receive來看出是否存在網(wǎng)絡(luò)問題，根據(jù)Client來判斷是否存在客戶端問題。
看看，挺簡單的吧！ ^_^
換個(gè)圖看看，Page Component Breakdown(Over Time)
很清楚吧，頁面元素都被cache了，說明場景啟用了browser cache，頁面的響應(yīng)時(shí)間只包括紅線和藍(lán)線。
Time to First Buffer Breakdown(Over Time) ，圖就不貼了，這個(gè)圖非常重要，也最復(fù)雜，這里的值不絕對，當(dāng)網(wǎng)絡(luò)狀況不好的時(shí)候，server time很可能包括網(wǎng)絡(luò)時(shí)間，因?yàn)楹芏囗撁嬖乇容^小（小于4k的樣子），在First Buffer就完成傳輸，所以一定要注意分析。
就嘮叨到這里吧，歡迎拍磚
昆汀.塔倫蒂諾，血漿愛好者
劇情簡單，卻能讓你血脈賁張，當(dāng)然你要先忍受昆汀的一貫喋喋不休，聽得我昏昏欲睡，打算回頭再過一遍
懷舊風(fēng)格的影像處理，火辣的大腿舞，血腥的撞車鏡頭（喜歡kill bill的tx應(yīng)該是見怪不怪了），極速飚車，拳頭，極度亢奮的表揚(yáng)和精彩的配樂(原聲大碟不要錯(cuò)過），如果你喜歡這些，so...
羅伯特.羅德里格斯的恐怖星球俺不太喜歡，和他之前拍的罪惡之城沒法比，如果你是cult愛好者，看看吧，斷腿機(jī)槍比較牛叉
刑房GRINDHOUSE：是指專門放映exploitation films的小影院，exploitation films也被稱作grindhouse films，昆汀和羅伯特的這部片子也是一部懷舊的exploitation film，熟悉他們兩個(gè)經(jīng)歷的可能知道，他們都是在這類電影的熏陶下長大的，并且是狂熱的愛好者，從他們之前拍攝的電影就可以看出
Exploitation film is a type of film that eschews the expense of "quality" productions in favor of making films on-the-cheap, attracting the public by exciting their more prurient interests. "Exploitation" is the show business term for promotion, and an exploitation film is one which relies heavily on the lurid advertising of its contents, rather than the intrinsic quality of the film.
Exploitation films feature forbidden sex, wanton violence, drug use, nudity, freaks, gore, monsters, destruction, rebellion and mayhem. Such films have existed since the earliest days of moviemaking, but they were popularized in the 1960s with the general relaxing of cinematic taboos in the U.S. and Europe. Since the 1990s, this genre has also received attention from academic circles, where it is sometimes called paracinema.
Ephraim Katz, author of The Film Encyclopedia, has defined exploitation as:
Films made with little or no attention to quality or artistic merit but with an eye to a quick profit, usually via high-pressure sales and promotion techniques emphasizing some sensational aspect of the product
del.icio.us Tags:
life ,
movie
作者：tacy lee
<container-descriptor>
servlet-reload-check-secs
The <servlet-reload-check-secs> element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it.
-
The value -1 means never check the servlets. This is the default value in a production environment.
-
The value 0 means always check the servlets.
-
The value 1 means check the servlets every second. This is the default value in a development environment.
A value specified in the console will always take precedence over a manually specified value.
resource-reload-check-secs
The <resource-reload-check-secs> element is used to perform metadata caching for cached resources that are found in the resource path in the Web application scope. This parameter identifies how often WebLogic Server checks whether a resource has been modified and if so, it reloads it.
-
The value -1 means metadata is cached but never checked against the disk for changes. In a production environment, this value is recommended for better performance.
-
The value 0 indicates not to do any metadata caching. Customers who keep changing their files must set this parameter to a value greater than or equal to 0.
-
The value 1 means reload every second. This is the default value in a development environment.
Values specified for this parameter using the Admin Console are given precedence.
native-io-enabled
To use native I/O while serving static files with weblogic.servlet.FileServlet, which is implicitly registered as the default servlet, set native-io-enabled to true. (The default value is false.) native-io-enabled element applies only on Windows.
<jsp-descriptor>
page-check-seconds
Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.
-
The value -1 means never check the pages. This is the default value in a production environment.
-
The value 0 means always check the pages.
-
The value 1 means check the pages every second. This is the default value in a development environment.
In a production environment where changes to a JSP are rare, consider changing the value of pageCheckSeconds to 60 or greater, according to your tuning requirements.
-
設(shè)置Initial Capacity等于Maximum Capacity
-
設(shè)置Statement cache（注意，對于每個(gè)打開的statement，DBMS都會(huì)維護(hù)一個(gè)cursor，這個(gè)值設(shè)置過大會(huì)導(dǎo)致 java.sql.SQLException: ORA-01000: maximum open cursors exceeded類似的錯(cuò)誤。當(dāng)然，你要清楚，statement cache的大小是指每個(gè)連接能cache的statement數(shù)，例如你設(shè)置connection pool size = 100 ,設(shè)置Statement Cache = 10，那系統(tǒng)最大維持的cursor為100*10）
del.icio.us Tags:
weblogic ,
tuning ,
tips
摘要: 作者：tacy.lee
一個(gè)簡單的java io測試，不同的實(shí)現(xiàn)對比看一個(gè)zip包的解壓速度
閱讀全文
一個(gè)簡單的ajax性能分析工具，比較實(shí)用。
1、下載Ajax View并安裝運(yùn)行，它會(huì)監(jiān)聽在8888端口
2、打開IE或者Firefox，設(shè)置代理：localhost:8888
3、打開你的ajax頁面，執(zhí)行
4、另外開一個(gè)窗口，打開http://fakeurl.com/?&AJAXVIEWREQUEST=GET=main.html
5、選擇左邊的鏈接JS Performance Statistics，你就可以看到具體的執(zhí)行時(shí)間
延伸閱讀：Javascript Performance
del.icio.us Tags:
ajax ,
profiler ,
performance ,
java
一個(gè)極具創(chuàng)意的firefox插件，如果你熟悉vim，這絕對是必選項(xiàng)
===== 快捷鍵 =====
* [f] 最具想象力的快捷鍵，有了這個(gè)，你基本上可以放棄鼠標(biāo)了
按f鍵之后，它會(huì)搜索你頁面上所有超鏈接和輸入框，并且在旁邊放置快捷字母,你只要通過這些快捷字母就能打開相應(yīng)的鏈接（或者是激活輸入框）
看到那些紅色字母了嗎，你用google搜索出的結(jié)果，假如你對第三條搜索結(jié)果感興趣，如果在以前你需要通過移動(dòng)鼠標(biāo)去點(diǎn)擊，現(xiàn)在呢？按下JO ;-) ,如果你對搜索結(jié)果不滿意，或者說想修改關(guān)鍵字重新搜索，你只需要鍵入HB,光標(biāo)就定位到google輸入框。
* h,j,k,l 這個(gè)熟悉vi的都不用介紹了，導(dǎo)航鍵
* H,L 前進(jìn)后退鍵
* Ctrl+n 下一個(gè)tab
* Ctrl+p 上一個(gè)tab
* Ctrl+6 前后兩個(gè)tab切換
* o url 在當(dāng)前tab打開url
* o 關(guān)鍵字 用瀏覽器的缺省搜索引擎搜索關(guān)鍵字(用當(dāng)前tab）
* t url 在新tab打開url
* t 關(guān)鍵字 用瀏覽器的缺省搜索引擎搜索關(guān)鍵字（用新tab）
* / 在當(dāng)前頁面搜索
* d 關(guān)閉當(dāng)前tab
* u 重新打開之前關(guān)閉的tab
* zi 頁面放大
* zo 頁面縮小
* zz 恢復(fù)頁面大小
===== 設(shè)置 =====
* I 忽略Vimperator鍵（這個(gè)主要是考慮一些ajax應(yīng)用，比如gmail，google reader）
* : 進(jìn)入命令行模式
* :set guioptions+=msT 顯示firefox的菜單，狀態(tài)欄，工具條
del.icio.us Tags:
firefox ,
plugin ,
vim
摘要: 作者：tacy lee
這篇blog就是用wlw發(fā)布的 ;)
配置很簡單：只要注意兩個(gè)地方：
1、Windows Live Writer不能正確識(shí)別blogjava的類型，然后會(huì)要你選擇你的服務(wù)，這里應(yīng)該選Metaweblog API
閱讀全文