天天躁日日躁狠狠躁AV麻豆-天天躁人人躁人人躁狂躁-天天澡夜夜澡人人澡-天天影视香色欲综合网-国产成人女人在线视频观看-国产成人女人视频在线观看

Remember: 我們是做產(chǎn)品的,不是搞學(xué)術(shù)研究的 & 用事實(shí)說話,不要臆斷

近來發(fā)現(xiàn),有很多同事在設(shè)計(jì)ASP.NET Application時(shí),選擇用字符串拼Html文本而不用GridView等控件,原因居然是“ASP.NET太慢”。看來有必要再次明確一個本質(zhì)問題:我們是做產(chǎn)品的,不是搞學(xué)術(shù)研究的;同時(shí)要強(qiáng)調(diào)一個習(xí)慣:要用事實(shí)去證明你的猜測,而不要臆斷。

一、Remember:我們是做產(chǎn)品的,不是搞學(xué)術(shù)研究的

直接貼一個前陣子的一封郵件,“全在郵件里面了”:

發(fā)件人: 
發(fā)送時(shí)間:
收件人:
主題: 答復(fù): 關(guān)于WebService的性能損失


這個問題里面,缺少對用戶場景的描述。

 
我認(rèn)為,我們實(shí)際應(yīng)該關(guān)心的并不是這兩種方式的性能究竟差別有幾倍,而是他們是否會對用戶、對業(yè)務(wù)產(chǎn)生影響。

 
在這個例子里面,1500次的訪問,WebService多出了5000毫秒,平均每次訪問多出了3ms。那么我有以下幾個問題:
1、當(dāng)用戶執(zhí)行一次操作的時(shí)候,會調(diào)用幾次Web Service,從而會多出多少毫秒?
2、多出的這些時(shí)間,是不是我們必須省下來,還是在允許接受的范圍內(nèi)、可以忽略不計(jì)?
3、如果用戶的一次操作確實(shí)需要繼續(xù)節(jié)省時(shí)間,是通過改接口方式更好更有效,還是通過其他方式(比如使用緩存、禁用ViewState、局部刷新等)更好更有效?

 
我覺得只有把這些用戶場景描述出來,才好決策。 只要放在正確、合適的環(huán)境之中,任何一個方法都有可能是好的方法。 


我認(rèn)為一個優(yōu)秀的軟件開發(fā)人員必須對程序的性能保持敏感。實(shí)際在.NET中,如果傳遞的數(shù)據(jù)量比較大,Web Service與Odbc方式的性能差距遠(yuǎn)不止3倍,另外使用反射與直接訪問的方式相比性能差別可能超過百倍,使用屬性與使用字段的方式相比性能也有幾倍的差距。

但同時(shí),我們不能局限在這些“倍數(shù)”中,要更多的關(guān)注這些差距所造成的最終影響,而不能單純的從性能差距的倍數(shù)去判斷是否使用某個技術(shù)。

就以差距明顯的反射來說。如果是直接訪問字段,只要執(zhí)行幾條cpu指令就夠了;但如果使用反射,則可能需要執(zhí)行幾百條cpu指令。他們的性能差距很明顯。但是,對于目前主頻動輒幾個G的cpu來說,這幾百條指令是我們不能接受的么?即便用戶的一次操作會觸發(fā)成百上千次反射、一共多執(zhí)行數(shù)萬條cpu指令,轉(zhuǎn)換成CPU時(shí)間也只是以微秒計(jì)。

反而是網(wǎng)絡(luò)傳輸、磁盤IO這些影響性能的大頭,也許將這些環(huán)節(jié)的性能提高10%,就會對用戶或者業(yè)務(wù)產(chǎn)生明顯的改善了。



發(fā)件人: 
發(fā)送時(shí)間:
收件人:
主題: 答復(fù): 關(guān)于WebService的性能損失


請架構(gòu)的同事一起評審一下吧


發(fā)件人:
發(fā)送時(shí)間:
收件人:
主題: 關(guān)于WebService的性能損失


寫了個簡單的測試,

訪問同一個數(shù)據(jù)庫表,訪問1500次,一個直接通過Odbc訪問,一個通過WebService封裝轉(zhuǎn)發(fā)一遍,

發(fā)現(xiàn)使用WebService后,花費(fèi)的時(shí)間大約是直接訪問的3倍左右

測試的數(shù)據(jù)如下,時(shí)間單位為ms


直接訪問數(shù)據(jù)庫時(shí)間:
2718.75
通過WebService訪問數(shù)據(jù)庫時(shí)間:
7750


直接訪問數(shù)據(jù)庫時(shí)間:
2656.25
通過WebService訪問數(shù)據(jù)庫時(shí)間:
7703.125


直接訪問數(shù)據(jù)庫時(shí)間:
2750
通過WebService訪問數(shù)據(jù)庫時(shí)間:
7656.25
 

鑒于這個性能損失比較大,ADS訪問配置庫時(shí)還是直接訪問數(shù)據(jù)庫吧,只是把對配置庫的訪問放到一個單獨(dú)的DLL中,避免混到一起就是。

NET技術(shù)Remember: 我們是做產(chǎn)品的,不是搞學(xué)術(shù)研究的 & 用事實(shí)說話,不要臆斷,轉(zhuǎn)載需保留來源!

鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請第一時(shí)間聯(lián)系我們修改或刪除,多謝。

主站蜘蛛池模板: 黄色一级毛片免费 | 动漫美女被羞羞动漫怪物 | 成人免费一级毛片在线播放视频 | 国产色综合久久无码有码 | 国产精品人妻一区免费看8C0M | 99re2.久久热最新地址 | 久久天堂网 | 亚洲人成色777777老人头 | 久久国产精品永久免费网站 | 91交换论坛 | 羞羞麻豆国产精品1区2区3区 | 色www.亚洲免费视频 | YELLOW视频在线观看免费版高清 | 第一精品福利导福航 | 久久精品国产欧美成人 | 亚洲合集综合久久性色 | 免费视频xxx | 伊人久久精品中文字幕 | 真人美女精美小穴 | 欲香欲色天天天综合和网 | 亚洲男人的天堂久久精品麻豆 | 俄罗斯性孕妇孕交 | 久久笫一福利免费导航 | 亚洲国产在线99视频 | 亚洲免费每日在线观看 | 任你躁精品一区二区三区 | 一级毛片西西人体44rt高清 | 午夜福利视频极品国产83 | 精品国产在线亚洲欧美 | 乌克兰16~18sex | 亚洲视频成人 | 偷拍自偷拍亚洲精品 | 日本电影护士 | 人淫阁| 一个人在线观看视频免费 | 午夜在线播放免费人成无 | 亚洲精品久久久午夜麻豆 | 亚洲精品久久无码AV片银杏 | 亚洲国产成人99精品激情在线 | 亚瑟天堂久久一区二区影院 | 亚洲在线国产日韩欧美 |