伺服器回應時間過長

我們先前討論了針對傳輸時間過長，來優化網頁內容的做法，現在接著討論其他因素導致效能不佳問題的建議解法。

建立連線時間過長的問題

當瀏覽器與伺服器端之間的建立連線等待時間過久，常見的狀況是因為伺服器既有的連線數已達設定上限值，新的連線要求送出時，得等待原有的連線釋放後才能取得，而原有的連線何時釋放，則會與伺服器端上所設定的Timeout參數有關。

另一個常見的原因，則是網站流量需求遠大於目前系統負荷上限，此時則需要觀察目前的系統資源使用量是否已達極限。透過設置網站伺服器的參數值（像是Apache的MaxClients），我們能夠調整同時可提供上線的連線數，以提高系統資源可用度。

假如網站上大部分網頁的內容元素較多，瀏覽器需要同時發出許多請求，才能完成頁面的構成時，則Keep Alive機制有必要啟動。

現行網站伺服器大都支援Keep Alive機制，這個機制的用意在於，相同的瀏覽器在設定的時間內，重複對同一個伺服器發出請求前，不需要反覆地建立及關閉HTTP連線，這麼作是期望能連續發出請求，而提升整個HTTP請求及回應的時效。而這樣的設定，也需同時搭配像是MaxKeepAliveRequests、KeepAliveTimeout等參數，才能發揮較佳的效果。

以MaxKeepAliveRequests而言，它是用來表示在同一個KeepAlive的連線時，允許接受的最大請求量，這個值與你的網站頁面構成元素的多少有關。頁面內容包含的元素愈多，在載入頁面時同時需發出的請求量就會愈高，相對這個參數值即需往上調設。

KeepAliveTimeout則表示等待連續請求時間的上限值，若訪客瀏覽單一頁面所停留的時間較長，像是新聞網站、部落客平臺網站而言，則可設定較長的KeepAliveTimeout時間；若是購物網站，訪客瀏覽商品頁的時間較短，則可設定較短的時間值。這些參考值的取得，可以透過網站流量分析軟體（像是Google Analytics）收集單一頁面停留時間，以及單一訪次瀏覽頁數等相關數據。

等待回應時間過長的問題

若網站將靜態與動態內容頁面隔離的設計架構，就會運用到應用伺服器的角色，以便能有效分隔不同內容的資源耗用需求。而在那樣的情況下，網頁的回應時間過長，通常會是卡在應用伺服器執行網頁程式，使得處理邏輯運算所花費的時間延長，或是耗在等待資料庫伺服器的資料存取時間上。

若是部分資料來源需連到第三方主機進行資料交換（像是信用卡資料授權，合作廠商紅利點數平臺之交易作業等），也會影響外部連線處理的時間。

網頁伺服器等待應用伺服器的回應時間過久

網站伺服器接到瀏覽器的請求，需要轉由應用伺服器處理時，會透過Connector建立連線，將請求以伺服器對伺服器的方式轉達（像是常見的mod_jk，AJP Connector等）。有時會因取得連線的時間過久，而造成整體回應時間過長。

我們可從兩個地方來檢視系統參數的設置是否得當。第一是針對Connector本身的配置參數來，這裡定義了從Connector向應用伺服器建立連線時所需要設定值，像是在Apache worker.properties中提到，針對單一Socket連線所需要的Timeout時間，以及關於連接池可制定同時連線數的Connection Pool Size及Connection Pool Timeout時間等。

第二則是就應用伺服器本身而言，檢視可接受Connector連入的maxThreads最大執行緒數量設定，看看與目前系統使用度之間是否還有上調的可能。
若是程式面的問題，則需要進一步以Profiling工具來找出問題所在，這些工具可以找出元件的方法執行所花費的時間，由此推斷是否合理進而優化。

應用伺服器等待資料庫的回應時間過久

有些情況是應用伺服器在等待資料庫伺服器，像是無法及時取得資料庫連線，或是資料存取的效能不佳，或是在同一個交易（Transaction）中，因執行多重SQL指令，以致處理時間過長所引起。

從取得資料庫連線的問題來看，目前幾乎應用程式都會透過應用伺服器本身提供的連接池（Connection Pool），或是以自行引用的開源框架支援的機制來處理，像是dbcp、Proxool、c3p0等。然而這裡的系統設定值需同步配合資料庫系統端的設定來調整，像是Pool的最大／最小連線數、連線有效之最大時間等。

若取得連線沒有顧慮，則需深入了解資料庫伺服器本身針對SQL執行效能的表現如何。一般從資料庫的管理介面可以取得相關資訊，像是Oracle Enterprise Manager在11g的版本，可以針對Top SQL Command進行統計分析，找出問題較大的命令進行優化。常見的處理方式會是改寫SQL指令，依資料存取方式加入索引鍵值，以及透過一些資料庫重整的功能提升效能（像是db shrink、Rebuild Index、Table Space重新規畫等）。

利用快取來處理重複存取的內容

網頁內容常利用快取（Cache）來加速瀏覽器端的顯示，分別透過不同網路節點分層提供，包括瀏覽器本身，以及不同伺服器主機上的機制等。

若是單純的靜態檔案內容，當瀏覽器確認內容未更新時，則會直接取用本地端的內容進行呈現。透過Firebug來觀察，該請求會是以304 Not Modified的狀態碼回應。網站伺服器可搭配像Apache的mod_cache、mod_proxy，代理伺服器則可採用開源專案中的 Squid Cache Server、HAProxy來實作。

而應用伺服器的快取機制，則會與開發使用的開源框架有關，在設計上會將常用的唯讀性資料、常叫用的服務及方法，或是構成網頁內容的樣版，讓應用伺服器先行讀取至記憶體，以利存取效率。像是利用Spring Framework中的EHCache，或是啟用Web Container中servlet/jsp的cache機制。

資料庫端的快取則依採用的產品而異。例如MySQL的Query Cache、Oracle的In-Memory Database Cache等。網頁的資料存取，盡可能設計得讓應用伺服器以相同的SQL指令對資料庫操作，才能發揮到資料庫端Cache的優點。

透過壓力測試來驗證系統調校後的結果

無論採用何種方法優化效能，最後仍需要確認調校結果是否真正能解決問題。通常，我們會將在離峰時間安排壓力測試，來驗證調整的結果。

以網站而言，壓力測試情境設計十分重要。不同性質的網站，訪客瀏覽動線與頁面流程是相異的，因此依訪客行為來設計出合乎邏輯及實際使用的腳本、配置合適的點閱比例，可讓測試更符合實務。

在工具上的使用，最常見的莫過於Apache專案中的JMeter了，針對不同性質的網頁都可以列入測試的範圍，而針對動態網頁的部分，亦可以設計傳入參數內容，模擬表單資料的送出，並自行定義字典檔，匯入資料，並執行不同條件的網頁查詢，可避免在壓力測試時，因重複網址及資料受到快取處理的關係，而無法真正測到實際資源的耗用度。

工具本身亦提供腳本錄製的方便功能，在點選瀏覽網頁的同時，亦同步產生JMeter腳本檔案內容，事後再調整，即可大功告成。
相同的效能問題，可以採取的解決方法有很多種，通常你需考量所選用的方法，會因執行面需要的時間，以及額外再投入在硬體及軟體的花費而定。然而，效能問題不容許拖延太久，如何在時間及成本間取得最佳解，則需妥善評估各項解法，才能做出最佳決策。