語錄一
某天,停車,圖方便隨便停在路邊,抱怨了兩句,ld隨即頂回一句:“只要有邊就能停”posted @ 2008-11-18 23:32 tacy lee 閱讀(246) | 評論 (0) | 編輯 收藏
2008年3月18日 #
posted @ 2008-11-18 23:32 tacy lee 閱讀(246) | 評論 (0) | 編輯 收藏
一直認為lob類型的性能要好過long,但是之前只了解到long的種種限制,oracle也是不推薦使用long類型,這幾天由于一個項目問題,產品里面一個表字段用了long類型,分析下來操作long的時候,性能有所影響,想把它改成lob,就簡單驗證了一下
首先創建兩個測試表:
create table test_long (a int primary key,b long);
create table test_clob (a int primary key,b clob);
用附件java代碼,往兩個表里面各插入100條數據,保證插入數據是一樣的,lob字段長度為10k(如果小于4k,oracle可以把它保存到到表內,不會存儲在表外,性能沒有問題,這個我基本確定,而且我們應用中這個字段經常會超過4k)。
做一個簡單查詢對比一下:
SQL> set autotrace traceonly;
SQL> select * from test_clob where a=1;
統計信息
----------------------------------------------------------
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;
統計信息
----------------------------------------------------------
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小,當然你可以把lob字段啟用緩存,把4次物理讀去掉,但還是多了(73-43)次邏輯讀,update也試了一下,lob產生的redo比long大,就不列出來了,有興趣的可以自己試試
測試下來,看來之前的認識不對,不確定的東西最好還是動手試試,當然對于新應用,還是不建議用long,畢竟oracle已經廢棄它了。
posted @ 2008-06-24 01:18 tacy lee 閱讀(456) | 評論 (0) | 編輯 收藏
用遠程桌面連接登入服務器的時候,你可能會經常碰到下面的情況:
也就是說,服務器的連接數已經滿了,很多時候,可能是別人異常斷開連接,導致連接沒有釋放,一般這時候你需要去機房登入服務器斷開連接,其實windows提供了tsdiscon命令來做這事情
posted @ 2008-06-22 17:12 tacy lee 閱讀(468) | 評論 (0) | 編輯 收藏
有時候,我們可能希望看到lr的出錯頁面:比如lr出錯,但是后臺服務器沒有錯誤日志,這時候,我們希望能看到錯誤頁面的內容來判斷問題出在什么地方,但是lr沒有提供類似的功能
我們可以通過一種變通的辦法來實現:
首先找到你出錯的頁面,保存該頁面到參數里面:
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的幾個設置:
1、Always send messages
2、continue on error (這樣才能保證運行lr_output_message)
這樣lr會把所有的lr_output_message輸出保存到日志文件
當然你不要下載資源文件,否則保存到的就不是html頁面了,可能是一個gif :(
最后,結合lr controller的錯誤信息,定位到出錯的vuser id,查看該vuser的log文件就能看到錯誤頁面了
非常有效的一個小技巧,用它解決了一個難纏的問題。
posted @ 2008-05-28 23:05 tacy lee 閱讀(834) | 評論 (3) | 編輯 收藏
posted @ 2008-05-14 10:17 tacy lee 閱讀(243) | 評論 (0) | 編輯 收藏
posted @ 2008-04-14 20:38 tacy lee 閱讀(4456) | 評論 (2) | 編輯 收藏
Sybase ASE有三種鎖模式:AllPages,DataPages,DataRows
Sybase的數據有table pages和index pages,最小分配單位為pages,不同的鎖模式對于table pages和index pages有不同的表現,具體如下:
Locking Schema | Locks on Index | Locks on Data |
All Pages | Page | Page |
DataPages | Not locked | Page |
DataRows | Not locked | Row |
如上表所示:
1、AllPages鎖模式對于并發的限制最高,他對index pages和table pages都加頁鎖(當頁被鎖住的時候,頁上的所有rows都不能被其他session訪問)
2、DataPages對table pages加頁鎖
3、DataRows:強烈建議用這個鎖模式,對于oltp應用,如果用前兩種鎖模式會導致頻繁死鎖
另外,DataPages和DataRows對于index pages的控制采用latch方式,一種輕量級的鎖機制(熟悉oracle會比較清楚)
對于Sybase ASE來說,鎖是非常寶貴的資源,不要長時間持有鎖,所以一般我們在寫應用的時候盡量減少長事務
另:Sybase ASE缺省的事務隔離級別:Read Committed
posted @ 2008-04-01 10:50 tacy lee 閱讀(926) | 評論 (0) | 編輯 收藏
一個用戶點擊就是一個用戶請求,一個webservice類似的調用也算一個請求,等等
一個用戶在某個時間點上當然只能發起一個用戶請求,一個用戶請求就是一個并發
我們一般糾纏在同一事物并發還是不同事務并發。
可能在一個時間點上,有100個用戶在發送瀏覽,查詢動作,10個用戶在下訂單,5個用戶在做付款動作,你說這個時間點上有多少個并發請求,當然是115個了
衡量一個系統性能主要靠的就是這個吞吐量(tps)
當然我們也非常關心同時100個用戶并發下訂單的時候系統是否能支撐(這是通常我們大部分人理解的并發),我們會說這是核心業務,我們要得出數據(是否要考慮背景業務呢,呵呵,很難說的清楚,我一般就不考慮)
posted @ 2008-03-18 15:33 tacy lee 閱讀(291) | 評論 (0) | 編輯 收藏