因爲不少園友反饋,有的組件不該該缺席、測試複雜度不夠、測試還缺少必定的公平。html
所以考慮在下一個版本中,確保在更加公平的前提下進行更高複雜度的測試 。
git
同時將分爲2組測試,純SQL組件及純ORM組件, 若是純SQL組件不足,就只進行純ORM組件的測試。
github
待加入測試組件有Dapper、PetaPoco/NPoco、Elinq、FluentData ,有更好的建議,請留言。
sql
--------------------------------------------------------------
數據庫
「啊!你在用ORM?會不會性能不好啊?」xcode
標題提到的組件「增刪改查」都實現了測試代碼,因此除了測試外,也能夠把此項目做爲各個組件的入門參考demo。
緩存
源碼下載:https://github.com/alifellod/DbAccessLibTest/archive/master.zipsession
git地址:https://github.com/alifellod/DbAccessLibTest 歡迎園友貢獻改進代碼。
併發
項目使用的是.Net Framework 4.0可使用2010或2012打開。 app
默認測試數據庫使用SqlServer
測試前,請先建立數據表Test(使用名爲Test的數據庫,若是不用這個數據庫,請更改數據庫鏈接字符串)
測試前清表:truncatetable Test
默認鏈接字符串是:Data Source=.;Initial Catalog=Test;Integrated Security=True
此程度測試代碼使用了接口規範,並無爲了省事耦合在程序裏,所以編寫修改測試代碼很是簡單,因此也但願各位園友本身寫上一段測試測試。
因爲這些組件基本都是第一次使用,因此可能致使部分組件測試代碼編寫並不合理,敬請指點。
注意:各組件的測試均採用同樣的測試思路,也即ORM對ORM,SQL對SQL,循環也是同樣的循環。
沒必要拘泥於15和23的區別,而是要區別10和100的區別,也就是在一個數量級別之間比較。
線程我分別寫了Task、ThreadPool和Thread的執行方式,根據本身的喜歡選擇。
先看兩張測試圖。
分別是ClownFish和EF的測試圖,X軸是線程名稱,Y軸是耗時。
特別說明: CYQ的數據是使用更新前的組件,在昨晚測試整理的。今天收到秋天園友的反饋,已經在git提交了更新,測試的數據也迴歸正常。
所以,數據也調整過來。(2013-07-27 13:53)
關於XCode的測試數據,請參看大石頭的說明。大石頭建議在大數據的訪問時使用此組件,並開啓緩存。
同時再也不接受新的組件更新,除非是在新的測試版本中,以免針對性的更新。
數據格式:平均值-最高值-最低值
測試順序:增、改、刪
100「線程」 查詢10次 增刪改
|
ClownFish |
Moon |
|
增 |
23-96-2 |
21-76-6 |
8-25-4 |
刪 |
16-49-2 |
15-37-5 |
4-18-2 |
改 |
46-116-3 |
23-56-3 |
7-33-3 |
|
CYQOrm |
EFOrm |
MoonOrm |
MySoftOrm |
NHibernateOrm |
PDFOrm |
XCodeOrm |
增 |
24-79-5 |
23-71-8 |
10-64-3 |
46-102-24 |
21-47-7 |
12-31-4 |
15-60-9 |
刪 |
11-61-4 |
61-137-17 |
10-29-3 |
41-267-15 |
41-103-9 |
20-54-3 |
340-623-173 |
改 |
29-182-18 |
37-113-15 |
5-15-2 |
110-195-52 |
37-128-7 |
17-50-3 |
364-476-246 |
1000「線程」 查詢10次增刪改
|
ClownFish |
Moon |
|
增 |
9-276-2 |
13-49-2 |
7-44-3 |
刪 |
22-125-2 |
7-43-3 |
9-41-3 |
改 |
20-299-2 |
10-123-3 |
8-66-2 |
|
CYQOrm |
EFOrm |
MoonOrm |
MySoftOrm |
NHibernateOrm |
PDFOrm |
XCodeOrm |
增 |
79-961-3 |
29-306-9 |
6-52-3 |
50-386-11 |
12-259-4 |
10-48-3 |
14-231-8 |
刪 |
29-471-4 |
43-321-11 |
14-95-2 |
78-386-13 |
45-237-7 |
22-90-4 |
362-729-177 |
改 |
30-438-3 |
59-334-12 |
27-215-14 |
106-647-18 |
42-294-4 |
17-128-3 |
410-755-199 |
查詢測試,數據行100W
100「線程」 查詢返回Top 100
使用沒有索引的列RowId排序
|
ClownFish |
Moon |
|
查 |
2-19-1 |
1-9-0 |
1-47-0 |
查詢採用的根據組件提供的分頁或者Top查詢功能。(moon及xcode使用的是分頁查詢)
使用沒有索引的列RowId排序
|
CYQOrm |
EFOrm |
MoonOrm |
MySoftOrm |
NHibernateOrm |
PDFOrm |
XCodeOrm |
查 |
1339-2220-281 |
1452-3668-735 |
5230-8032-3241 |
1287-1670-240 |
3372-6264-954 |
2629-3825-836 |
1696-5363-716 |
使用有索引的列Guid排序
|
CYQOrm |
EFOrm |
MoonOrm |
MySoftOrm |
NHibernateOrm |
PDFOrm |
XCodeOrm |
查 |
16-32-13 |
5-8-3 |
5967-14644-1639 |
2-5-1 |
7-127-2 |
1-17-0 |
1-9-0 |
通過測試,發現線程越多,越容易出現問題「超時時間已到,可是還沒有從池中獲取鏈接。出現這種狀況多是由於全部池鏈接均在使用,而且達到了最大池大小。」致使訪問很不穩定。
一個好的數據訪問層應該是能夠優雅的接受並處理大併發的訪問,而不該該僅僅只盯住表面上的測試數據(除非有數量級上的差距)。
整個程序框架怎麼才設計出色,更加優雅的面對請求,纔是應該花更多心思去考慮的。
從上面也能夠看到,ORM性能其實並無通常人想象的那麼糟糕。
最後看看程序的代碼是怎麼樣的。
項目目錄
測試代碼接口
ClownFish-SQL測試代碼
PDF-SQL測試代碼
CYQ-ORM測試代碼
EF-ORM測試代碼
Moon-ORM測試代碼
MySoft-ORM測試代碼
NHibernate-ORM測試代碼
XCode-ORM測試代碼
測試耗時監控
測試完整邏輯代碼 ,300多行,慎點。
到底是選擇ORM而不寫Sql,仍是 爲了追求性能,而避開ORM,就看本身的狀況來取捨了。
選擇一個組件的時候,能夠考慮這幾方面:穩定性、性能、易用性、是否保持更新、是否有較好的文檔手冊、使用者社區怎麼樣、是否開源。
上面提供的組件測試代碼也能夠看到這些組件的代碼風格,喜歡語法糖的不妨好好看看,到底更喜歡哪一種風格。
綜合考慮選擇。
QQ交流羣:9524888 ,若是想提交測試代碼,能夠直接發給我,我加上去。
更新修正說明:
因爲ClownFish提出測試的時候,使用了匿名對象,所以修改成SQL的直接執行,測試數據以下。
因爲1000線程的測試,在500左右,就出現鏈接超時問題,不能提供測試數據,有興趣的朋友,本身運行測試。對此形成誤解,請諒解。