經(jīng)由上面的處理，一臺web加一臺數(shù)據(jù)庫也能蒙受必定壓力的訪問了。壓力是多大？按我的教訓是15分鐘4000PV左右是可以支持的，再多的話，例如8000，那就很有難度了。當然條件是你的網(wǎng)頁中，或者說被主要訪問的網(wǎng)頁中不能有iframe。當然，還要受具體帶寬多少，機器配置是否足夠，用戶操作是否散布平均等因素影響。

前多少年出了一個xml+xslt靜態(tài)方案，能夠解決網(wǎng)站作風變更問題。csdn的論壇改版（詳細忘卻哪年了），就應用過這種方案。這種方案是對html靜態(tài)方案的發(fā)展。不外仿佛后果并不是很幻想,網(wǎng)站、數(shù)據(jù)庫的衍變之路(三)，詳細會碰到什么問題，貧道沒用過，也說不明白。==!

圖1.1

于是乎，衍生出了進程外緩存。進程外緩存，是把緩存的數(shù)據(jù)放置到另外一個進程中，脫離了IIS。這種應用個別是windows service。本機的話可以用匿名管道，聯(lián)網(wǎng)機器的話可以用Remoting、socket等方式與ASP.Net交流數(shù)據(jù)。這種方式效力沒有放在IIS內(nèi)部解決快，但是運行穩(wěn)固是它的特色。最有名的運用就是MemCached。這種方式是緩存了數(shù)據(jù)而不是頁面，數(shù)據(jù)在內(nèi)存中，拿到ASP.Net頁面進行數(shù)據(jù)綁定。這點是這種利用與前面三種最大的差別。

到了這里，該松一口吻了，所有問題都讓咱們解決了。但是跟著網(wǎng)站的發(fā)展，用戶的增添，拜訪量一直加大，系統(tǒng)又遇到瓶頸了。

2、動態(tài)頁面作載體的靜態(tài)方案
這種方案是圖1,網(wǎng)站、數(shù)據(jù)庫的衍變之路(一).1衍生品，把靜態(tài)文件換成aspx文件。現(xiàn)在好了，可以解決更新風格、模板的問題了。由于生成的文件是aspx，就可以使用.net自帶的模板解決方案了！當然，像某些部門需要顯示用戶相干數(shù)據(jù)的話，那沒方法，仍是得用js調(diào)用的辦法。這個方案主要是用來解決同一風格網(wǎng)站更新風格問題的。

二、緩存式計劃

1、Html靜態(tài)方案

圖1.1是最常用的靜態(tài)化處理方式。IIS得到懇求交給ASP.Net，依據(jù)門路ASP.Net斷定是否已經(jīng)生成這個要求的靜態(tài)文件，假如存在，則直接輸出文件，如果不存在，則讀取數(shù)據(jù)生成靜態(tài)頁，并輸出。這種方式最容易懂得，準入門檻低，很輕易就想到了。

話接前文《網(wǎng)站、數(shù)據(jù)庫的衍變之路(一) 》。上回說到為了進步網(wǎng)站負載而進行靜態(tài)化處置。

一、靜態(tài)化的處理方案（特指天生文件方法）

這樣好像解決了問題，然而新的問題來了。生成靜態(tài)后的頁面，所有人看到的都是一樣的，并且現(xiàn)在數(shù)據(jù)庫的數(shù)據(jù)更新了，現(xiàn)在怎么辦,網(wǎng)站SEO心得體會？這個時候，如果不想對體系進行大的變動的話,網(wǎng)址規(guī)范化的新標簽：canonical，最好的措施是用一段js調(diào)換掉需要按用戶顯示不同的處所，至于數(shù)據(jù)更新后靜態(tài)文件更新的方式，制訂一套策略就可以了。當然，這樣并不解決所有問題，例如，當初網(wǎng)站的整體風格都須要轉(zhuǎn)變，豈非全體生成一遍嗎？

ASP.Net就提高了現(xiàn)成的頁面緩存方案,編程入門經(jīng)驗教訓分享，用起來感到還不錯。這種頁面緩存式方案實質(zhì)上也是靜態(tài)化處理，不過這局部靜態(tài)內(nèi)容是放到了內(nèi)存中。由上篇文章講到的內(nèi)存與硬盤速度的狀態(tài)，就可以想到這種方案，速度比靜態(tài)化的快。這種方案也存在部分區(qū)域需要特定顯示問題，可以用局部靜態(tài)化，或者也可以用js調(diào)用的方式處理。這種方式也不是完善的，重要表示在，一旦緩存了很大的內(nèi)存，當ASP.Net過程池回收時，IIS容易逝世掉。