歡迎來到“管理角”這個版，新一期的月刊專欄專注于 weblogic 服務器的管理、配置、處理和開發方面。

　　開辟這個專欄的目的是為了向大家介紹在使用weblogic sever時，能普遍用到的非j2ee開發方面的問題。開發者和管理者同樣會發現這個專欄非常有價值，因為這些文章既適用于開發又適用于最終產品的應用。此外，它很大程度上利用了來自于該領域和工程實驗室的經驗，它提供了對實際問題的詳細解答。

　　jsp預編譯的必要性

　　本文著眼于移除潛在的系統性能瓶頸，它通過解決一個最普通的問題??在服務器運行時間中的jsp (javaserver page)編譯的系統開銷問題，這個問題困擾著幾乎所有的j2ee發展計劃。雖然jsp是在j2ee應用范圍內呈現動態html視圖的理想選擇，但在某種程度上它們會影響性能，這比錯誤的更令人討厭，給人的第一感覺是該程序很慢。

　　根據j2ee規范，jsp主要是html文件，在它里面包含著java代碼用來和其他的系統組件進行交互以及動態的顯示信息。規范規定所有的j2ee編譯應用服務器應當支持jsp，客戶請求一個特定的jsp，將：

　　● 轉換jsp從html格式成為servlet類型的java類（java源格式），用簡寫的jsp符號代替完全符合規定的java語法

　　● 將新產生的java源文件編譯成.class字節碼形式

　　● 在新編譯的類上執行適當的接口方法并且對客戶端請求返回響應。

　　雖然從發展的觀點來看對于在表示層內管理動態html的產生這是最好的途徑，但它影響到服務器的運行時間環境，要求jsp被解析、轉變成java代碼，并且在它去處理一個特定的客戶端請求之前被編譯。對最終用戶明顯的影響是，一個響應將會被延遲知道給定的jsp文件被編譯通過?？紤]到一個特定的用戶請求可能用到兩個或多個jsp文件，因此編譯狀態必需的時間增加了很多倍。

　　對第一個請求一個特定的jsp頁面并且迫使被請求的文件進行初始編譯的終端用戶，會感覺應用程序很慢并且沒有響應。 雖然這樣的感覺可能存在，但是對于特定的jsp文件的編譯過程通常在給定的應用服務器虛擬機實例的生命周期中完成一次。 因此，它對性能總體上的影響被考慮成一種障礙，而不是對應用程序總響應時間的一個嚴重的障礙。然而，在生產環境中為了傳送基于jsp的j2ee應用程序的生產系統，必須克服jsp的缺陷并且對最終用戶進行透明的編譯。

　　這樣，生產環境如何能受益于jsp文件，還要避免運行時編譯的性能打擊？答案是簡單的：執行一個一般作為jsp預編譯的過程。 借用jsp預編譯，已經被預編譯的在脫機環境中的jsp文件和他們的編譯結果被部署在生產環境中。如果結果類文件的預編譯和部署正確的完成，應用程序服務器將會為jsp文件運行先前的編譯類，并且在運行中將不強制對特定的請求進行再編譯。 這樣產生了一種情況，應用程序的操作避免了多余的編譯開銷，允許系統管理員移除對系統總性能會造成影響的一個已知的瓶頸。

　　不同的方法論和途徑

　　沒有人懷疑jsp預編譯的承諾聽起來令人興奮。 然而，為了要實現這樣的承諾，你必須首先了解能夠執行這個技術的不同途徑，以及它們各自優點和缺點。

　　運行應用程序進行強制預編譯

　　用于實現jsp預編譯最顯而易見的方法是在產品發布前，通過請求在應用程序中的所有可能的jsp頁面，因此編譯在終端用戶訪問站點前完成。它既可以通過第一次人工瀏覽整個站點時完成也可以通過從測試系列應用程序或其他腳本語言的客戶端（例如loadrunner 或 silkperformer）發動自動請求來實現。 當使用這種方法（可能是所有的jsp預編譯方法中的最簡單的而又較下策的一個方法）時，他的缺點很快就顯現出來了。也許最大的缺點是很難實現跨集群環境，在集群環境中，用該方法對于單一節點的實例發送的請求依集群中的節點數量成倍的增加。而且，當這個集群是由一個或更多的web服務器或硬件負載權衡者來代理時，更難保證在一個集群的環境中每個服務器實例都進行jsp預編譯，因為一般沒有方法來搞清代理最初把請求轉到哪個應用服務器。此外，在應用服務器每次重啟時，這個方法必須執行，當站點很小時，不能一次實現所有的編譯就會很痛苦。因此，我們不推薦這種jsp預編譯的方法。

商業源碼熱門下載www.html.org.cn

　　使用編譯工具來實現預編譯

　　因為人工執行一個站點應用程序來強制jsp預編譯在真實的產品環境中是一個較大的缺點，在預編譯運行期間選擇編譯jsp，使其變成為servlets變得更令人心動。幸運地，wls提供了二個方法。第一種方法在服務器啟動部署一個特定的web應用程序的時候執行預編譯（declarative預編譯），第二種方法是命令行java工具（weblogic.jspc）允許過程在完全脫機的情況下處理（程序方式的預編譯）。兩種方法都有它們的優點，程序方式的預編譯在兩者中有更靈活的選項，并且提供更讓人無法抗拒的理由來使用它。

　　declarative預編譯

　　對于在wls下公布的預編譯，一個特定的web應用程序（獨立的或者作為ear的一部分）能夠被配置，因此所有的jsp在應用程序部署（服務器啟動時）和重新部署（運行時）期間里被預編譯。對web-inf/ weblogic.xml部署描述符要做必要的配置變化，使用預編譯指令，如下：

　　在一個特定的web應用程序上進行部署（或重新部署），如果上述的參數被設定成真， wls 將會在war內嘗試預編譯所有的jsp文件，在程序中從 web 應用程序的根目錄下循環的運行它的方法( 略過web-inf) 。以. jsp 或 .jsp為擴展名的文件都變成了編譯的對象。 被編譯后的文件被以適當的包目錄結構形式被放置在web 應用程序的臨時工作目錄下面（默認在web-inf子目錄中，除非在 weblogic.xml 里有特別說明）。

　　這個方法是到目前為止進行jsp預編譯最方便的途徑（“flick-a-switch” 途徑），他有許多指出來毫無意義的缺點。如果一個錯誤在jsp的編譯期間或在部署(或重新部署) 的時候發生，web 應用程序的預編譯將會在例外處暫停。另外，如果在一個特定的web應用程序里面有許多jsp文件的情況，declarative預編譯顯著的影響著部署時間，阻斷部署直到所有的文件都被編譯。對于大型的應用程序，當出現數以百計的jsp 文件以declarative預編譯被執行的時候，這種部署時間趨向以分鐘來計算 (在某些情況10到15分鐘，其他情況可能更長時間)。設想開始一個服務器實例，在一個特定的web應用程序周期內進入部署狀態用declarative 預編譯激活。如果在應用內有很多的jsp文件以及部署，接近完成時就已經花費了大量的時間，在編譯期間由于拋出一個例外而突然失敗，當然會引起挫折感。雖然起先看起來比較方便，但declarative 編譯對生產系統管理造成重大的風險，因此應該在經過慎重的考慮后再使用它。

　　程序方式的預編譯

　　在wls下最可靠的預編譯jsp的方法是使用java命令行，weblogic.jspc，它位于wls安裝的lib目錄之下的weblogic.jar文件中。這個工具允許開發者在發展階段和在部署前解決編譯時間問題的時候編譯需要的jsp文件。它也為生產系統提供一個有能力實現jsp預編譯的管理員。這種用法的主要好處是：

　　● 文件可以被預編譯一次然后可以被多次部署。（這不被服務器實例的重復利用所影響）

　　● 編譯時的例外可以被預先解決而不影響部署。

　　● 類可以通過集群部署。

　　使用weblogic.jspc的缺點是需要人工干涉，并且它在開發時并當在jsp文件變得過時的時候必須被重新運行。然而，考慮到前面的兩個方法的討論，我們幾乎不能將這種不方便當成該方法的一個缺點，因此推薦它作為最可靠和最靈活的機制來實現jsp預編譯。