建站
咨詢
售后
建站咨詢
新聞中心
不使用ASP.NET緩存機制的情況
創(chuàng)新互聯(lián)服務(wù)項目包括蘆溪網(wǎng)站建設(shè)、蘆溪網(wǎng)站制作、蘆溪網(wǎng)頁制作以及蘆溪網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，蘆溪網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到蘆溪省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！
上回說到了Memcached的性能問題，的確，緩存不是***的，但沒有緩存是萬萬不能的？還真有這么干的. PlentyofFish就是這樣做的, 它也是互聯(lián)網(wǎng)上巨頭中為數(shù)不多的采用WISC(Windows + IIS + Sql server + C#)架構(gòu)的網(wǎng)站, MS不能老拿MySpace說事, 現(xiàn)在當然不會放過這個機會大肆宣傳, 但是諷刺的是人家根本不用那些“看起來很美”的服務(wù)器控件，與其說是使用了.Net技術(shù)不如說是借用了這個平臺而已. 他們的頁面輸出絕大多數(shù)都是使用構(gòu)造字符串要不就是Response.Write出來的,簡單即是美，他們在寫程序的時候即是嚴格遵守這個規(guī)則，反過來想想CommunityServer里面多達7層的繼承關(guān)系的控件, 它看起來有點象是這個樣子:(基本的)(網(wǎng)頁的)(模版化的)(相冊基本模版化的)(相冊模版化的)(相冊可更換風格的)XXX控件，瞧這一長串定語，它在每一層繼承里面都實現(xiàn)了不同的特性, 結(jié)構(gòu)其實還是蠻清晰的, POF有點象什么呢，手工打造的奧迪，性能沒的說，就是麻煩點。那些B4 Discuz!NT的朋友是不是應該反思一下了呢:)
話說回來, 這并不意味著那堆微軟件挖空心思弄出來的Control就沒有用了, 但對于中小應用來說我們更需要的是開發(fā)效率，再說負載量達不那么大，有過度優(yōu)化之嫌, 合適的就是***的，能快速弄出讓用戶滿意的東西才是最重要的。
ASP.NET緩存機制以外，其他值得注意的地方
我們來看看它里面的一些值得玩味的地方吧:
1. ***的照片請求都是由他們的服務(wù)器來完成處理的，但是它們都被緩存在內(nèi)存中，并且大小都在2KB以下.
3. 使用Gzip技術(shù)雖然增加了30%的CPU開銷但從節(jié)省的帶寬情況來看是值得的.
4. 沒有使用Asp.Net的緩存機制，因為數(shù)據(jù)更新太快了, 一旦它進入緩存就過期了.
5. 大量使用 if,else 或者 while + Response.Write這樣的簡單語句來實現(xiàn)功能.
6. 負載均衡（好象沒有誰不用的）
每天3千萬的頁面訪問量，服務(wù)器只有2 個WebServer + 3個DB Server，優(yōu)化功夫?qū)嵲谑橇说?
以上就對ASP.NET緩存機制進行了深一步的探討：開發(fā)效率與性能優(yōu)化，應該尋找一個合適的平衡。
本文來自沙加的博客：《.Net下的分布式緩存(3)--如果我們沒有緩存會怎么樣》
【編輯推薦】
- .NET分布式緩存之Memcached執(zhí)行速度檢測
- 如何避免ASP.NET緩存占用系統(tǒng)資源
- .NET緩存機制探討與比對
- 概述ASP.NET緩存機制
- ASP.NET數(shù)據(jù)緩存之數(shù)據(jù)緩存淺談
本文標題：再談ASP.NET緩存機制：開發(fā)效率與優(yōu)化的平衡
鏈接分享：http://fisionsoft.com.cn/article/dpgggci.html
