上次示範程式自動化的威力，透過微軟的 ADO.Net Entity Framework 4.1 如何大幅度減少程式開發時間及簡化開發程序，更而推論出 I.T. 肥上瘦下的結果。
但是，針是沒有兩頭利的，我在「學生揀相手機網頁」中使用了 ADO.Net Entity Framework 4.1（以下簡稱 EF）來作資料庫存取介面，完成整個程式，真係好快手就搞掂，只需兩個星期就創作完成（比起以往估計要一個月），跟著發放到伺服器，最後做壓力測試（stress test），以為可以收工之際，點知發現得出103 pages/sec的結果。
下！無理由慢得咁緊要架？一諗就估到是 EF 出事，於是馬上搜尋下，睇下有無其他人都有同樣經驗，果然外國有很多高手都有類似發現。咁唔掂喎，咁慢，會拖慢我的客人運作，也好大可能影響生意。嗯！又要花腦汁諗計了…
我要考慮的規則是，1：不能失去 EF 的自動化好處，2：改善資料庫存取速度，如果真係做到的話，真係「針有兩頭利」。諗足一日，試左幾個方法，終於俾我諗到最佳方法，就是自已開發一個物件程式庫 (object library)，模擬 EF 的資料庫存取介面，用自已的方法，來取代微軟的EF資料庫存取介面。請看以下兩個 EF 呼叫程式 (Calling methods)：
以上可見，第一個是微軟官方文件所述方式，第二個是我自已創作的程式庫物件(library object)方式，兩個方式都極為相似，大家同樣是利用 EF 所自動化下產生出來的資料庫物件 (database object: Company)。兩個方式的執行時間如下：
結果是：我創作的方法快過微軟 7.867 倍，差唔多 800%。
咁先似樣架馬！跟著把成個揀相系統，改寫為我的新方式(用物件：clsDbNatConnect)，再做壓力測試，最新的 stress test 結果是 878 Pages/Sec（請看下圖），原先是103 Pages/Sec，即是，現在每秒可以應付 878 個瀏覽人數，客戶應該可以放心做生意了。
後記：EF4.1 慢的原因是 Linq 翻譯至 SQL 語法過程中，在背後做了後多重組投影動作，是我睇唔到的。（資料來源：請按此）
* 版權聲明: 版權屬於不同產品的公司擁有
* 免責聲明: 本文或短片內容只供示範或參考作用，對觀看者造成任何結果、影響並不負責
但是，針是沒有兩頭利的，我在「學生揀相手機網頁」中使用了 ADO.Net Entity Framework 4.1（以下簡稱 EF）來作資料庫存取介面，完成整個程式，真係好快手就搞掂，只需兩個星期就創作完成（比起以往估計要一個月），跟著發放到伺服器，最後做壓力測試（stress test），以為可以收工之際，點知發現得出103 pages/sec的結果。
下！無理由慢得咁緊要架？一諗就估到是 EF 出事，於是馬上搜尋下，睇下有無其他人都有同樣經驗，果然外國有很多高手都有類似發現。咁唔掂喎，咁慢，會拖慢我的客人運作，也好大可能影響生意。嗯！又要花腦汁諗計了…
我要考慮的規則是，1：不能失去 EF 的自動化好處，2：改善資料庫存取速度，如果真係做到的話，真係「針有兩頭利」。諗足一日，試左幾個方法，終於俾我諗到最佳方法，就是自已開發一個物件程式庫 (object library)，模擬 EF 的資料庫存取介面，用自已的方法，來取代微軟的EF資料庫存取介面。請看以下兩個 EF 呼叫程式 (Calling methods)：
以上可見，第一個是微軟官方文件所述方式，第二個是我自已創作的程式庫物件(library object)方式，兩個方式都極為相似，大家同樣是利用 EF 所自動化下產生出來的資料庫物件 (database object: Company)。兩個方式的執行時間如下：
咁先似樣架馬！跟著把成個揀相系統，改寫為我的新方式(用物件：clsDbNatConnect)，再做壓力測試，最新的 stress test 結果是 878 Pages/Sec（請看下圖），原先是103 Pages/Sec，即是，現在每秒可以應付 878 個瀏覽人數，客戶應該可以放心做生意了。
後記：EF4.1 慢的原因是 Linq 翻譯至 SQL 語法過程中，在背後做了後多重組投影動作，是我睇唔到的。（資料來源：請按此）
* 版權聲明: 版權屬於不同產品的公司擁有
* 免責聲明: 本文或短片內容只供示範或參考作用，對觀看者造成任何結果、影響並不負責
留言