Kettle正常轉換速度
| 場景 |
正常 |
不正常 |
| 數據庫操作 |
3k-2w條/秒 |
2000條/秒以下 |
| 文件操作 |
2w條/秒以上 |
1w條以下 |
| http、get、set |
比數據庫慢 |
|
容易產生性能問題的場景
查詢類：
數據庫查詢：數據庫查詢、數據庫連接、插入更新
Web查詢 ：http/get/set webservice
計算類
格式轉換（字節與字符互相轉換，日期）、
轉換一般用計算器和JavaScript方法。
排序類
排序、合並連接（依賴於排序）、分組（依賴於排序）
調優的關鍵：Rowset
Rowset是兩個步驟之間的緩存（大小可以自己設置）
如何找到性能瓶頸：觀察Rowset，運行ktr文件時觀察下面的窗口值（100/0表示輸入100條記錄，輸出0條記錄。如果輸入遠大於輸出，就說明這個步驟來不及處理，就是瓶頸。）
Rowset值的設置：編輯》設置》雜項》記錄集合里的記錄數》10000，表示緩存里的最大記錄數就是10000
其他觀察方法：性能圖，和步驟度量效果一樣。
如何提高性能
合理增加索引
數據庫查詢：盡可能多的使用相等=判斷來篩選數據；如果是等值查詢，表就建hash索引；如果是比較查詢，就建B樹索引
增加復制數：查詢類。多線程，2-8個線程一個步驟。具體自己調整。
加大緩存：排序類，查詢類。
集群：查詢類、運算類、排序
更換其他的實現方式：JavaScript、Java類
注意日志級別：Rowlevel的性能是Basic級別的1/10
.spoonrc在.kettle目錄下
注意死鎖問題
數據庫表死鎖：讀寫同一個表（表現是ktr在running，卡在那不動）
轉換本身死鎖：
這里死鎖的原因：排序記錄要求將所有的記錄都讀取到之后再排序，緩存設置10000，發完要下游處理完才能再次發送。這樣以來排序需要更多數據，而表輸入是復制記錄到兩個下游，一個要更多的數據，一個不要更多的數據。所以，死鎖。
解決辦法：
