最近由於工作需要,建設了一個ASP.NET網站,在美國Godaddy上購買的主機. ( 順便鄙視一下國內的網域名稱主機服務商,又貴又爛,技術員還經常很隨意的修改伺服器,造成不可預計的問題.) 說說網站建設和使用過程中的一點經驗. ( 商業原因, 網址我不方便透露,抱歉.)
我在建設和使用的過程中碰到一些問題, 網上搜了好久,很多都沒有好的解決方案, 幸好,目前我的網站運行已經比較完美,所以寫點東西放上來, 希望能給碰到類似問題的同志一點協助. ( 我太理解為一個莫名其妙問題困擾的心情了. 程式員都不容易
1. 伺服器主機
前面已經說過, 如果對國內網速要求不是特別高 ( 一般的訪問沒問題,飛快.), 建議到Godaddy 購買, 很便宜. 我的150G Windows 主機加網域名稱大概付了200美元左右,帶獨立IP地址 ( 現在又更便宜了). 他們的服務還可以, 給發的郵件都有回.
2. ASP.NET, JAVA, PHP.
現在好像和流行做類似的對比,作為程式員,我也是這麼過來的,理解.
我的看法是:無所謂.
ASP.NET, JAVA, PHP 等等,只是工具,只要能實現你的商業目的,達到功能效能要求就可以. 作為老闆,並不關心你用什麼語言(我的話可能俗了點,但是是事實). 所以只要選一個比較熟悉,或者比較喜歡的用起來就可以了. 就我自己而言,因為以前開發C++/MFC的,現成就有Visual Studio 2005,所以就用ASP.NET了.
編程到後面,其實都一樣,來來去去就那麼些個東西.我不敢說窺到了什麼本質,一點感受而已.就像作業系統一樣,不論是Windows還是Linux,不都是那些東西嗎? 做系統編程為什麼可以用POXIS規範寫出統一的代碼?我想就是因為所有作業系統本質上都是類似的,總要用到線程,檔案,進程,通訊,同步等等等等. 做網站也是一樣,無非就是根據使用者請求,動態返迴響應流嘛,不論JAVA, ASP.NET, PHP 在這點上都是一樣的,實現上也大同小異.
如果是新手, 不要過於在意語言工具, 選一種你看得順眼的, 用起來. 熟練之後觸類旁通. 如果你精通ASP.NET,讓你寫JAVA代碼,估計有2個星期訓練一下,足夠. 反過來也一樣.
要我說,痛點在於美工,怎麼排版配色,讓網頁看起來賞心悅目,真是一門學問...
3. 最大的問題是碰到
“驗證檢視狀態 MAC 失敗。如果此應用程式由網路場或群集承載,請確保 <machineKey> 配置指定了相同的 validationKey 和驗證演算法。不能在群集中使用 AutoGenerate。”
我總結了一下,發現在以下這種情況的時候比較容易出現這個黃頁錯誤:開啟網頁後,放一段時間,大概是等Session到期的時間,然後執行一個Postback操作,必出.
事實上,我的網站只有一個主機,不可能是什麼叢集,而且根據Gooogle搜來的一些提示,我也沒用資料庫綁定的控制項.(我一向比較反感資料庫繫結控制項,喜歡自己編排結果.)
剛開始的時候找到一篇文章(具體內容忘記了),說是把ViewState之類的加密全部設定為 "Never",不僅不安全,而且也沒效果(至少我這裡沒效果).
後來實在沒辦法了,抱著姑且一試的想法,在 web.config 添加了<machinekey>配置,居然一舉成功,從此再也沒見到這個黃頁面. (到現在網站已經穩定運行6個月.)
由此,根據黃頁提示和實際經驗,認定應該是使用了不同的machinekey的原因. 按照微軟的說明,同一台機器同一個網站執行個體運行起來後應該不會再產生一個不同的machinekey, 但是也許有什麼BUG導致.net架構在某種情況下,如果你在web.config沒有指定,它又產生了一個隨機的machinekey,導致和之前的不同,最終導致上面的黃頁出現. 當你指定了machinekey之後,.net架構不再重複產生,所以不會有解密失敗的問題.
以上是我個人猜測,沒有經過測試和理論驗證,如果您有什麼見解,務必請您告知我一下,非常感謝.
另外, http://aspnetresources.com/tools/keycreator.aspx
可以產生machinekey放到你的 web.config中. 也可以自己產生,能google到相關代碼.
4. 主版頁面
用主版頁面能夠很方便的是所有的網頁都保持一個統一的風格. 但是同樣會帶來一些問題: 控制項ID會被自動修改.
這是我不喜歡的,我寫的代碼,憑什麼瞎給我改名字? 使很多JavaScript代碼編起來很麻煩.
不知各位有什麼辦法不用主版頁面而達到同樣目的(保持統一風格)?
5. 關於Session_End 執行的問題
由於網站規模不大而且只有一個主機,所以把Session都放在記憶體中, 在Session_End 裡設定使用者的狀態, 目的是統計線上人數.
運行一段時間發現Session_End經常沒有被執行, 確定不是代碼的問題, 我在本地機器上測試時沒有問題的. 也許是伺服器壓力比較大,或者什麼別的原因.
後來出於偶然,把伺服器升級到IIS7.0 (之前是IIS 6.0), 發現Session_End的執行情況居然大有好轉,大概在95%以上. 有3個可能的原因:
(1) 伺服器軟硬體環境的問題,因為升級到ISS 7.0 後會遷移到另一台伺服器.
(2) IIS程式的問題,也許IIS6 有什麼BUG,到IIS 7解決了.
(3) 我在web.config指定了 Session的配置, 雖然都是預設配置,但是都顯式寫在裡面 <sessionState mode="InProc" timeout="20"></sessionState>, 根據"MAC驗證失敗"的經驗,被搞怕了.
總之就做了以上3點改變,Sesssion_End執行情況就大致達到要求了,線上人數統計非常準確.很遺憾,我這裡的條件不允許我做進一步測試找出哪條是真正原因.如果您有結果,希望您能告訴我一聲,非常感謝.
6. 資料庫分頁
資料庫是我的弱項,資料量大的時候最好能夠實現分頁查詢. 不過我這裡都沒有做. 主要是網站規模不大,沒有需求.
今後有什麼新的體會心得,我會繼續更新這篇文章, 如果您有什麼心得體會, 歡迎交流. querw@sina.com
再說一個題外話, 米線的<<情迷唐古拉>>專輯真好聽 -_-!