⑴ 怎樣提高IIS伺服器性能，加快伺服器速度
1、應該分配和釋放多個對象
你應該盡量避免過量分配內存，因為內存分配可能是代價高昂的。釋放內存塊可能更昂貴，因為大多數分配算符總是企圖連接臨近的已釋放的內存塊成為更大的塊。直到Windows NT? 4.0 service pack 4.0，在多線程處理中，系統堆通常都運行得很糟。堆被一個全局鎖保護，並且在多處理器系統上是不可擴展的。
2.不應該考慮使用處理器高速緩存
大多數人都知道由虛擬內存子系統導致的hard 頁錯誤代價很高，最好避免。但是許多人認為其他內存訪問方法沒有什麼區別。自從80486以後，這一觀點就不對了。現代的CPUs比RAM要快得多，RAM至少需要兩級內存緩存 ，高速L1 緩存能保存8KB數據和8KB指令，而較慢的L2 緩存能保存幾百KB的數據和代碼，這些數據和代碼混合在一起。L1 緩存中內存區域的一個引用需要一個時鍾周期，L2 緩存的引用需要4到7個時鍾周期，而主內存的引用需要許多個處理器時鍾周期。後一數字不久將會超過100個時鍾周期。在許多方面，緩存像一個小型的，高速的，虛擬內存系統。
至於和緩存有關的基本內存單元不是位元組而是緩存列。Pentium 緩存列有32個位元組寬。Alpha 緩存列有64個位元組寬。這意味著在L1 緩存中只有512個slot給代碼和數據。如果多個數據一起使用（時間位置）而並不存儲在一起（空間位置），性能會很差。數組的空間位置很好，而相互連接的列表和其他基於指針的數據結構的位置往往很差。
把數據打包到同一個緩存列中通常會有利於提高性能，但是它也會破壞多處理器系統的性能。內存子系統很難協調處理器間的緩存。如果一個被所有處理器使用的只讀數據，和一個由一個處理器使用並頻繁更新的數據共享一個緩存 列，那麼緩存將會花費很長時間更新這個緩存列的拷貝。這個Ping-Pong高速游戲通常被稱為"緩存 sloshing"。如果只讀數據在一個不同的緩存 列中，就可以避免sloshing。
對代碼進行空間優化比進行速度優化效率更高。代碼越少，代碼所佔的頁也越少，這樣需要的運行設置和產生的頁錯誤也會更少，同時占據的緩存 列也會更少。然而，某些核心函數應該進行速度優化。可以利用profiler去識別這些函數。
3.決不要緩存頻繁使用的數據。
軟體緩存可以被各種應用程序使用。當一個計算代價很高時，你會保存結果的一個拷貝。這是一個典型的時空折中方法：犧牲一些存儲空間以節省時間。如果做得好，這種方法可能非常有效。
你必須正確地進行緩存。如果緩存了錯誤數據，就會浪費存儲空間。如果緩存得太多，其他操作可以使用的內存將會很少。如果緩存得太少，效率又會很低，因為你必須重新計算被緩存 遺漏的數據。如果將時間敏感數據緩存得時間過長，這些數據將會過時。一般，伺服器更關心的是速度而不是空間，所以他們要比桌面系統進行更多的緩存。一定要定期去除不用的緩存，否則將會有運行設置問題。
4.應該創建多個線程，越多越好。
調整伺服器中起作用的線程數目是很重要的。如果線程是I/O-bound的，將會花費很多時間用來等待I/O的完成-一個被阻塞的線程就是一個不做任何有用工作的線程。加入額外的線程可以增加通量，但是加入過多的線程將會降低伺服器的性能，因為上下文交換將會成為一個重大的overhead。上下文交換速度應該低的原因有三個：上下文交換是單純的overhead，對應用程序的工作沒有任何益處；上下文交換用盡了寶貴的時鍾周期；最糟的是，上下文交換將處理器的緩存填滿了沒用的數據，替換這些數據是代價高昂的。
有很多事情是依靠你的線程化結構的。每個客戶端一個線程是絕對不合適的。因為對於大量用戶端，它的擴展性不好。上下文交換變得難以忍受，Windows NT用盡了資源。線程池模型會工作得更好，在這種方法中一個工人線程池將處理一條請求列，因為Windows 2000提供了相應的APIs，如QueueUserWorkItem。
5.應該對數據結構使用全局鎖
使數據線程安全的最簡單方法是把它套上一把大鎖。為簡單起見，所有的東西都用同一把鎖。這種方法會有一個問題：序列化。為了得到鎖，每一個要處理數據的線程都必須排隊等候。如果線程被一把鎖阻塞，它沒有在做任何有用的事。當伺服器的負載較輕時，這個問題並不常見，因為一次可能只有一個線程需要鎖。在負載很重的情況下，對鎖的激烈爭奪可能就會成為一個大問題。
設想在多車道高速公路上發生了一個意外事故，這條高速公路上的所有車輛都被轉向一條狹窄的道路。如果車輛很少，這一轉換對交通流的速率的影響可以忽略。如果車輛很多，當車輛慢慢並入那條單通道時，交通阻塞會延伸幾英里。
有幾種技術能夠減少鎖競爭。
· 不要過分保護，也就是說，不是非常必要不要鎖住數據。只有需要時才去持有鎖，而且時間不要過長。不要在大段代碼周圍或頻繁執行的代碼中沒必要地使用鎖，這一點很重要。
· 對數據進行分割，使它能夠用一套獨立的鎖保護。例如，一個符號表可以按標識符的第一個字母分割，這樣在修改名字以Q開頭的符號的值時，就不會去讀名字以H開頭的符號的值。
· 使用APIs的Interlocked 系列（InterlockedIncrement，等）自動修改數據而不需要鎖。
· 當數據不是經常被修改時可以使用多讀者/單作者（multi-reader/single-writer）鎖。你將獲得更好的並發性，盡管鎖操作的代價將更高並且你可能會冒餓死作者的危險。
· 在關鍵部分使用循環計數器。參見Windows NT 4.0 service pack 3中的SetCriticalSectionSpinCount API。
· 如果你不能得到鎖，使用TryEnterCriticalSection並做一些其他的有用的工作。
高競爭導致serialization，serialization導致降低CPU的利用率，這促使用戶加入更多的線程，結果事情變得更糟。
6.不必注意多處理器機器
你的代碼在多處理器系統上比在單處理器系統上運行得還要糟，這可能是件令人惡心的事。一個很自然的想法是，在一個N維系統上運行N次會更好。性能很差的原因是競爭：鎖競爭，匯流排競爭，和/或緩存列競爭。處理器都在是爭奪共享資源的所有權，而不是做更多的工作。
如果你一定要編寫多線程應用程序的話，你應該在多處理器盒上對你的應用程序進行強度測試和性能測試。單處理器系統通過時間分片地執行線程而提供一個並發性的假象。多處理器盒具有真正的並發性，競爭環境和競爭更容易發生。
7.應該始終使用模塊化調用；他們很有趣。
利用同步模塊化調用來執行I/O操作對大多數桌面應用程序來說是合適的。但是，他們不是使用伺服器上的CPU（s）的好方法。I/O操作要花費上百萬個時鍾周期來完成，這些時鍾周期本來可以被更好地利用。利用非同步I/O你能得到顯著提高的用戶請求率和I/O通量，不過增加了額外的復雜性。
如果你有需要花費很長時間的模塊化調用或I/O操作，你應該考調撥多少資源給他們。你想使用所有的線程還是有個限制？一般地，使用有限的幾個線程要好些。構建一個小的線程池和隊列，利用隊列來安排線程的工作完成模塊化調用。這樣，其他線程就可以拾取和處理你的非模塊化的請求。
8.不要進行測量
當你能夠測量你所談論的事情並用數字表達它時，這就表示你對他有了一定的了解；但是如果你不能用數字表達時，你的知識是貧瘠的不能令人滿意的；這可能是知識的開始，但這時你簡直不可能將你的思想提高到科學的水平。
- Lord Kelvin (William Thomson)
如果不測量你就不能了解應用程序的特性。你在黑暗中摸索，一半是靠猜測。如果不識別性能問題，你就不能做任何改進或做出工作量計劃。
測量包括黑匣子測量和profiling。黑匣子測量的意思是收集由性能計數器（內存使用，上下文交換，CPU利用等）和外部檢測工具（通量，反映時間等）所顯示的數據。為了profile你的代碼，你編譯代碼的一個工具版，然後在各種條件下運行它，並收集關於執行時間和過程調用頻率的統計數據。
測量如果不用於分析的話就一點用都沒有。測量將不僅告訴你有問題，而且甚至能幫助你找到問題發生在哪，但它不能告訴你為什麼會有問題。對問題進行分析以便你能正確地改正他們。要從根本上解決問題而不是停留在表面現象。
當你進行改動後，要重新測量。你要知道你的改動是否有效。改動也可能會暴露其他性能問題，測量-分析-改正-再測量的循環就會重新開始。你也必須要有規律地進行測量，以便發現性能衰退問題。
9.應該使用單一用戶，單一請求的測試方法。
書寫ASP和ISAPI應用程序的一個通病是只用一個瀏覽器去測試應用程序。當他們在Internet上應用他們的程序時，他們才發現他們的應用程序不能處理高負載，並且通量和反應時間另人可憐。
用一個瀏覽器測試是必要的但是不夠的。如果瀏覽器反應得不夠快，你就知道你有麻煩了。但即使它在使用一個瀏覽器時很快，你也不知道它處理負載的能力如何。如果十幾個用戶同時請求會發生什麼事？一百個呢？你的應用程序能容忍什麼樣的通量？它能提供什麼樣的反應時間？在輕載時這些數字會怎樣？中等負載呢？重載呢？在多處理器機器上你的應用程序會如何？對你的應用程序進行強度測試，這對於找出bugs發現性能問題來說是基本的。
類似的負載測試考慮適用於所有的伺服器應用程序。
10.不應使用實際環境。
人們往往只在幾個特定的，人工的環境（如下benchmarks）下調整應用程序。選擇和實際情況相對應的各種情況，並為針對各種操作進行優化，這一點很重要。如果你不這樣做，你的用戶和評論家一定會這樣做，並且他們將依此來評判你的應用程序的好壞。
⑵ 如何對網站進行性能優化
一、刪除功能：重要數據偽刪除，刪除校驗用戶（避免A用戶可以刪除任何人數據）。文件上傳預覽刪除功能不能做伺服器文件刪除，不要為了節省伺服器資源給用戶留下介面。如果要資源有限，那麼在刪除的時候也需要做用戶校驗（文件命名或文件路徑關聯用戶ID等）
二、發簡訊:基本上沒有人願意自己和簡訊運營商直接對接簡訊業務，一般都是通過第三方簡訊服務商購買簡訊。在用戶主動獲取簡訊的時候前端做圖片驗證碼校驗，後端做發送量，發送間隔校驗（圖片驗證碼是可以被機識別的）。做簡訊日誌記錄，這些日誌可以為前面的後台校驗提供數據，系統運行期間的各種好處就不一一舉例了。重要功能做語音驗證碼，比如注冊送現金的活動，簡訊驗證碼可以被識別
三、頁面數據獲取：用戶平凡的刷新數據會加大伺服器壓力，當然誰也擋不住用戶刷新是吧，但是減少主動刷新次數也是一個減小伺服器壓力的方法，咱不能自己坑自己吧，(Table頁切換做校驗，有數據就不再拉取等等)
四、前端靜態資源做CDN，可以提高用戶訪問速度，減少伺服器壓力
五、用戶輸入做SQL注入，javascript腳本注入
六、用到的Ajax請求：做ajax加攔截器，通過消息頭過濾掉非ajax的地址欄訪問，（誰然不一定能全部攔截，但是攔掉一部分小白還是可以得，總不能是個人就能攻擊吧）
七、用戶輸入數據校驗，輸入文字長度，數字輸入大小，int 、long等數據類型合理使用，(積分兌換的時候用戶只有1積分，你讓他輸入兌換積分，你輸入21000000000，int 接收的時候，超出了范圍成了負數1永遠大於負數)，還有一點很重要，你的任何校驗都不要依靠前端，畢竟前端是為用戶的體驗而生的，為了自己的安全還是多寫點後台校驗吧，
八、異常捕獲：不要將異常信息拋給用戶，首先不美觀，其次這些錯誤信息中可能含有SQL錯誤，通過這些sql可以了解到你的資料庫結構
九、前端數據獲取的時候減少不必要欄位輸出，java面向對象，表數據面向對象，本來頁面只需要兩個數據，結果你返回了一個實體，前端可已查看到你資料庫表結構，多看幾個頁面那麼你的資料庫設計就給了人家了呢
十、用戶信息加密傳輸，一定不要把重要數據留在客戶端，泄密重要信息的責任是要你承擔的哦
十一、 現在越來越多人使用阿里雲伺服器，做客戶項目的時候伺服器是客戶購買的，當然阿里雲賬戶客戶也有，你的配置文件不加密客戶就能看見你的系統配置，結合上面的搞搞你的資料庫，那你的產品還有什麼秘密，至於代碼，你覺得他值錢么
十二、 前端JS 腳本 和頁面分離，壓縮或加密，不要你的團隊倖幸苦苦開發的唯美的頁面和效果，被人家一個ctrl+s拿去回家研究了，何況你的js中還有大量的邏輯
十三、 線程安全:
1、synchronized同步 （有序性、可見性），
2、使用生產者消費者模式，(喚醒notify()，等待wait())
3、volatile同步（可見性，非有序性，只在無基礎數據的賦值操作，直接操作主內存，減少主內存復制到工作內存的cpu消耗）
十四、 資料庫讀寫分離的時候要注意個別業務讀也要讀在主庫上（避免主從同步失敗或延時）
⑶ 網站如何做優化
優化的方式後很多種，提供一些實用的吧
1、盡量用靜態頁面，如htm,html這樣會減少伺服器腳本輸出的時間，提升訪問速度，你看一下各大門戶網站都是生成的靜態頁面。如果你是asp
php
等動態CMS，可以自己製作一個凈化插件
2、減少圖片或者將圖片分成小塊，讓圖片下載浪費更少的時間
3、如果你的網站經常出現iis連接數超出導致的iis忙，可以換一個伺服器或者空間
4、更新網站特別是上傳盡量在早起進行，這樣對訪問者的干擾比較少
5、採用執行效率較高的程式，如果自己編寫有困難，可以下載一些專業程式稍加改造
⑷ 網站運行一段時間後變得很慢，要重啟IIS才會變快為什麼
一般是兩個原因，一是網站有一個進程很消耗資源，然後導致系統的資源耗盡了，然後又不能釋放，導致資源枯竭，重啟後資源釋放
或者是你的網站訪問量過大
針對第一個原因，請檢查你的網站，對於第二個原因，我覺得可能性不大，因為你的伺服器還算不錯的
⑸ 如何進行網站性能優化
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問，伺服器會通過301轉向到/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： ），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ ）、php accelebrator()，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
⑹ 如何優化IIS設置給網站提速
1.不同的站用不同的應用程序池．方法：應用程序池－新建－應用程序池－名稱可自定義，然後設置，網站－屬性－主目錄－應用程序池，選擇剛新建的應用程序池．
2.應用程序池優化．方法：應用程序池－選擇要優化的那個程序池－屬性－回收工作進程(分鍾)設為200的．最大虛擬內存300，最大使用的內存150.大家可以根據網站需求做出一些調整．
3.IIS網站優化：A,網站－啟用日誌記錄，勾掉，這功能沒啥用．B,文檔－默認內容文檔，把除了網站首頁文件名名稱的其它內容文檔刪掉，因為每次訪問網站首頁的時候都要查詢一下這個．C，網站－主目錄－讀取(勾上)，索引資源(勾上)，寫入(勾上)，主目錄－配置－應用程序擴展，只保留網站需要擴展名，如ASP.PHP，其它的可以全部刪呢．
4.WEB 服務擴展優化．有ASP程序網站的啟用Active Server Pages，有PHP程序網站的啟用PHP服務,沒有則禁止，其它的服務擴展如不是自己設置的可以禁止．
5.GZIP壓縮．讓網頁體積變小，方法：WEB服務擴展－添加一個新的WEB服務擴展－擴展名就填寫(GZIP)吧，這樣好記些．－要求的文件－添加C:\WINDOWS\system32\inetsrv\gzip.dll一般就是這個路徑，－設置狀態擴展為允許．然後在返回網站－屬性－服務－壓縮應用程序文件(勾上)，壓縮靜態文件(勾上)，臨時目錄自己在硬碟設定一個，要有IIS_WPG這個用戶的完全許可權．編輯C:\WINDOWS\system32\inetsrv目錄下的MetaBase.xml文件．編輯文件的時候要暫停IIS Admin Service服務，用文本打開MetaBase.xml搜索IIsCompressionScheme主要修改HcFileExtensions和HcScriptFileExtensions後邊的參數．
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="css
html
js
xml"
HcOnDemandCompLevel="9"
HcPriority="1"
HcScriptFileExtensions="asp
php"
注意啊．要修改相同的兩處．
修改完成後，保存．然後重啟IIS服務，或者重啟器，就能看到效果呢．
⑺ 如何配置IIS處理多並發請求及存在的問題
通過這個方法可以查看系統匯流排程數和當前可用線程數。
ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);
在隊列請求數達到120左右時，通過此方法，得到maxWorker=1600，而availableWorker=1472
因為伺服器是16核的，ASP.NET4.0默認每核可以使用100個線程，所以maxWorker是1600，1600-120=1480，大致相等。
⑻ 網站性能優化怎麼辦
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、Javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問www.xxx.com，伺服器會通過301轉向到www.xxx.com/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的免費php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
⑼ 如何查看IIS並發連接數及性能優化39
如果要想知道確切的當前網站IIS連接數的話，最有效的方法是通過windows自帶的系統監視器來查看。
一、運行-->輸入「perfmon.msc」.
二、在「系統監視器」圖表區域里點擊右鍵，然後點「添加計數器」.
三、在「添加計數器」窗口，「性能對象」選擇Web Service，「從列表選擇計數器」選中Current Connection，「從列表選擇實例」選中你要統計的站點，最後點擊「添加」按鈕.
查看IIS連接數，還可以在「運行」-->輸入「netstat -a」命令來查看，不過由於顯示結果太多太雜，很難統計HTTP的連接總數，所以不推薦使用此命令來查看。
⑽ 怎麼樣設置IIS讓網站訪問提速優化
伺服器在一定流量後或者因為網站程序的剛需求．而網頁卡或無法訪問，導致訪問下降體驗差，今天就這個問題做個較全的教程，讓網站飛起來．
1.不同的站用不同的應用程序池．方法：應用程序池－新建－應用程序池－名稱可自定義，然後設置，網站－屬性－主目錄－應用程序池，選擇剛新建的應用程序池．
2.應用程序池優化．方法：應用程序池－選擇要優化的那個程序池－屬性－回收工作進程(分鍾)設為200的．最大虛擬內存300，最大使用的內存150.大家可以根據網站需求做出一些調整．
3.IIS網站優化：A,網站－啟用日誌記錄，勾掉，這功能沒啥用．B,文檔－默認內容文檔，把除了網站首頁文件名名稱的其它內容文檔刪掉，因為每次訪問網站首頁的時候都要查詢一下這個．C，網站－主目錄－讀取(勾上)，索引資源(勾上)，寫入(勾上)，主目錄－配置－應用程序擴展，只保留網站需要擴展名，如ASP.PHP，其它的可以全部刪呢．
4.WEB 服務擴展優化．有ASP程序網站的啟用Active Server Pages，有PHP程序網站的啟用PHP服務,沒有則禁止，其它的服務擴展如不是自己設置的可以禁止．
5.GZIP壓縮．讓網頁體積變小，方法：WEB服務擴展－添加一個新的WEB服務擴展－擴展名就填寫(GZIP)吧，這樣好記些．－要求的文件－添加C:\WINDOWS\system32\inetsrv\gzip.dll一般就是這個路徑，－設置狀態擴展為允許．然後在返回網站－屬性－服務－壓縮應用程序文件(勾上)，壓縮靜態文件(勾上)，臨時目錄自己在硬碟設定一個，要有IIS_WPG這個用戶的完全許可權．編輯C:\WINDOWS\system32\inetsrv目錄下的MetaBase.xml文件．編輯文件的時候要暫停IIS Admin Service服務，用文本打開MetaBase.xml搜索IIsCompressionScheme主要修改HcFileExtensions和HcScriptFileExtensions後邊的參數．
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="css
html
js
xml"
HcOnDemandCompLevel="9"
HcPriority="1"
HcScriptFileExtensions="asp
php"
注意啊．要修改相同的兩處．
修改完成後，保存．然後重啟IIS服務，或者重啟器，就能看到效果．