許多
web站點在初建時，由於需求不明確，需求變化太頻繁，以及追求進度等諸多原因，第一版的站點多是凌亂的，難以維護和管理的。為此在站點進入穩定維護期的時候，進行優化是十分有必要的。選擇在進入穩定維護期後進行優化，是因為這時需求已經基本明確，需求變化不會太嚴重，又有「既有站點」的經驗與教訓可供參考，而且「既有站點」能同時應用，時間也會較為充裕。
根據「既有站點」的實際情況。選擇優化的方式：「部分調整改進」或者「完全重構」。如果「既有站點」是架構設計大部分較為合理，僅有小部分不太理想，就「部分調整改進」不合理的地方；如果「既有站點」架構嚴重不合理，難以維護，甚至是凌亂至極，僅是一堆**的堆砌而已，就不得不選擇「完全重構」。但無論採用哪種方式優化，以下第一步都是必須進行的。
1，分析「既有站點」：羅列「既有站點」已經實現的功能，及其功能的實現方法，評估這些功能是否滿足需求，以及實現這些功能採用方法的執行效率。這些羅列應該是整理成文件的，可以在已有的開發文件（如果存在的話）基礎上整理補充。
如果在進行第一步之前很難決定是選擇「部分調整改進」，還是「完全重構」，就在完成第一步之後再作決定。所需求的功能大部分都已經實現，並且執行效率也能夠接受，就選擇前者，否則就選擇後者。但我相信大多數參與過「既有站點」開發的人員僅憑直覺就能決定是「部分調整改進」還是「完全重構」。若選擇「部分調整改進」的方式進行優化，第一步整理出來的文件可以補充到已有開發文件（如果本來就不存在這樣的文件，可以將整理出來的文件補充為開發文件
)的「詳細設計」部分。若選擇「完全重構」，開發文件也基本上是需要「重構」。在「重構」文件的時候，第一步整理出來的文件，糟粕之處可以作為教訓來借鑑，在重新設計的時候加以避免，精華部分可以作為經驗來參考，繼續沿用。
選擇「部分調整改進」的方式進行優化，接下來需要做的工作就是：
2，根據第一步分析的結果，改善實現不合理的功能。如果還有未實現的功能，進行補充。 3，
優化**，增強**的可維護性，如改善**的結構，補充注釋等。 4，
完善文件（很多時候因為
很多原因，乙個專案開發完了，並沒有留下多少有價值的文件，雖然軟體工程一直在號召大家避免這樣，但事實上很多時候確實這樣，那就現在補救
），使站點更利於維護。
選擇「完全重構」的方式進行優化，所需要做的工作就要多些了。所謂的「完全重構」其實就是重新開發，但又不同於第一次開發。「重構」時，需求絕大部分應該是明確的了，如果需求仍是變來變去，那沒必要進行「重構」
2，參考第一步分析的結果，找出那些實現很困難的功能需求，重新考慮它的合理性，有沒有相對容易實現的、好的替代。訂立新的需求，與策劃部門重新確認，或改或棄協商解決那些原本難以實現的功能。
因為有些可能是無關緊要的功能，但實現起來成本卻又很高，如果還很複雜的話，還有可能是系統的隱患。
以下的步驟就跟開發新站點差不多了。只是比第一次開發相對容易些。 3
5，將第一步中整理出來的好東西應用在新的「重構」的文件「詳細設計」部分。
當然「重構」還有許多應該考慮的地方，比如：人員安排，時間安排，過程控制，這些我還在摸索中。
WEB站點效能優化實踐
第一步 後台優化，啟用頁面快取 實驗站點首頁後台邏輯並不複雜，不超過10個sql查詢，通過檢視時間線，本站在獲取html文件時，花費的時間不到總響應時間的20 優化之前沒有使用快取，所有的資料都是從資料庫讀取，這裡，我們使用靜態頁面快取，將首頁整個頁面完全的存放在快取中 關於yii靜態頁面快取的使用...
建立Web站點
1.網上有乙個教程，已經寫得非常明白，從花生殼到建站過程，在此不再重複 2.網頁版啟用花生殼網域名稱 3.通過iis搭建郵件伺服器和ftp伺服器 4.路由器配置 5.配置遠端訪問本機器 路由器配置與前面配置的一樣，考慮是如何在ubuntu中安裝起花生殼。主要參照的是花生殼網上的文章 2.解壓到指定目...
Web站點安全監控
阿里雲大學課程 web站點安全監控 課程介紹 web站點安全監控認證旨在幫助學員了解乙個典型的web站點的監控需求與目標，課程對比了採用傳統方法實現站點監控的方式與優缺點，幫助學員快速掌握阿里雲的雲監控以及雲監控的主要功能。通過學習雲監控的站點級監控 主機級監控 自定義監控等功能對乙個web站點進行...