压缩生成jsp的数量，减少系统的编译负载

近兩天為了搜索引擎橫沖直撞的故事，開始修正多jsp的框架。所謂多，是相對于過去重複性極高的servlet的方案而言的，實際上我的jsp重用程度高 到不能再高。如果說多，比起我見過的一般的jsp網站，jsp的數量一般只是他人的十分一以下。代碼量更是少得可憐，原因在于幾乎所有邏輯都已經封裝了。

即 使是這樣仍是有著再次壓縮的空間，而且，盡管重新達到整網一頁沒有必要，（那是使用servlet達到的，運行效果甚佳）,但依靠URL重寫的協助，整 網按功能在十來頁以來完成一個極複雜的多用戶多單位商業發布系統還是可以做到的。但問題來出現了，俺當初爲什麽要做到多目錄多文件自動複雜的JSP框架 呢？

第一個原因很直接，那是因爲沒有使用URL重寫這件武器；當時並沒有意識到這件武器結合一般的JSP可以産生如此威力；這個恐怕是最根本的原因；

第二個原因是對于多用戶多單位達到可信賴的權限控制沒有把握，希望通過不同的目錄設置對應的環境常量設定達成絕對可靠的訪問控制——這條今天隨著使用體驗的加深，證明可以通過單目錄判斷也可以達到。

第三個原因仍然存在，就是由于要保留多用戶多單位系統下的絕對自定義空間，需要提供獨立的文件目錄，在沒有URL重寫的協助，實際上不使用多目錄多文件是做不到的。

唔， 大概這是當初設定方案的主要考慮因素。從實際效果上看，在用戶不多，訪問量也不算太大的情況下，的確沒有什麽問題；在用戶多，訪問量也大但是運行時間 已經不短的情況下，也沒有什麽大問題；最大的問題大于剛剛完成升級到主服務器上或修改了關鍵文件時，大的訪問量造成多個文件同時編譯，而這些JSP文件一 般都會不同程度調用同一個組件，由此産生的編譯死鎖造成一至一次的發布失敗，需要重啓甚至幾次才能度過這個發布後的震蕩期。

這樣，就産生 了必須加以優化，減輕發布後，以及維護性修改後，系統需要承擔編譯的消耗。如上所言，現在可以壓縮成若幹個高度重用的文件，這樣，無論負載量 有多大，産生編譯死鎖的機會成級數降低了。另外，原來不太注意引用的類別，現在也要注意一點了，根本實際的目的，嚴格使用最低消耗的方案：
１、如果沒有變量共享，就不用file include;
2、靜態內容文件使用c:import;這樣允許頁網人員任意填寫不會造成重新編譯的要求；
３、動態內容但不具備變量共享的，使用c:import動態網頁或jsp:includepage（好象沒有什麽區別），同樣可以縮小編譯請求的影響面；

當然，最終的解決方案是完全實現靜態網頁發布。在完成靜態發布的升級以前，上述優化對于提供目前系統的承載量，估計還是有很大作用的。