Smart C# Compiler

Jeffrey — Tue, 08 Jan 2008 21:58:01 GMT

前陣子幫同事追查問題，由於懷疑主機上的程式版本有誤，便找來Source Code，與Reflector反編譯(Decompile)主機上DLL得到的Code比較，在一段程式上發現了小小的差異: Souce Code裡是先將DropDownList的SelectedValue先存到變數中，再將該變數當成呼叫另一個函數的參數；而Reflector中看到的卻是直接將DropDownList.SelectedValue直接被當成呼叫另一函數的參數。

程式寫法的差異，讓人懷疑上線的程式版本有誤。但同事印象中從頭到尾不曾用過這種寫法，追查上線記錄則顯示版本管理出錯的機率極低，到底是怎麼一回事? 幾經波折，最後在其他地方找到錯誤的根源，與程式邏輯無關，證實了程式版本並沒有任何問題。但引發一個有趣的結論: "DLL反編譯的結果與Source Code可能存在差異"，之前在探討Nullable Value Type時，曾有類似的經驗，莫非這次又遇到?

一些效能討論文章中提過Compiler本身會做一些最佳化，剛才提到Source Code將DropDownList.SelectedValue存成變數，變數只被用了一次--當成呼叫函數時的參數。少了這個變數不會對邏輯有任何影響，還可以省下宣告/建立變數的成本，的確是種最佳化。

為了印證這點，我寫了以下的程式，還順道驗證一下上回提過的靜態字串相加會直接被Compiler做掉的理論，程式如下:

using System;

using System.Collections.Generic;

using System.Text;

namespace SmartCompiler

    class Program

        static void Main(string[] args)

            int j = 0;

            string s = "Hello " + "World!";

            string t = s;

            Console.Write(t);

            int i = 3 + 5;

            Console.Write(i);

用Reflector解析一下，有幾個地方被"最佳化"了:

1.變數j宣告了卻從未用到，Compiler直接忽略，在DLL中完全未現身。
2.由於s只被用來指定給t，所以就直接用t取代s。
3."Hello World!"直接變成一個字串指定給t。
4.Compiler直接算好3+5=8指定給i。

Compiler真是愈來愈聰明了，不過不代表以後程式可以亂寫，再交給Compiler去調。Compiler能做的小修正有限，省下來多半只是幾個Tick的極微時間，有時數百萬個Compiler最佳化也抵不上Coding時的一個小疏忽，只能當成錦上添花。

講到Coding時應注意效能，最近又再度見識到在上萬次迴圈中反覆做Database查詢的"好"程式，一整個囧!

KB-Rapid-Fail Protection of IIS 6

Jeffrey — Thu, 19 Jul 2007 20:04:43 GMT

對一台IIS 6進行壓力測試時，因壓力過大Web不支倒地，接著再連上Web，出現的都是HTTP 503 Service Unavailable。

查看Event可以看到5個接連的W3SVC Warning及一個W3SVC Error。

Warning Event 1011 from W3SVC 共有四個

伺服應用程式集區 'DefaultAppPool' 的處理序與 World Wide Web Publishing 服務通訊時發生嚴重錯誤。處理序識別碼為 '3808'。資料欄位含有錯誤號碼。
A process serving application pool ApplicationPool suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '3808'.

接著是Error Event 1002 from W3SVC

正在自動停止應用程式集區 'DefaultAppPool'，因為在伺服該應用程式集區的處理序中發生許多失敗。
Application pool 'DefaultAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

同事小熊子分享了他的經驗，原來這是IIS6所謂的Rapid Fail Protection保護機制。當IIS因為程式不良或遭到惡意攻擊時，造成Worker Process Crash，IIS會自動重啟一個新的Worker Process繼續提供服務；但如果新啟動的Worker Process接連Crash，IIS就會停用該Application Pool，以免持續不斷重啟新Worker Process的沈重負擔把Server搞掛(參考)。

預設值是5分鐘內發生5次異常就會觸發Rapid Fail Protection，這就是為什麼在事件簿中看到5個Warning+1個Error的理由。Rapid-Fail Protection的設定UI如下:

黑暗執行緒 : Tips, Performance

Smart C# Compiler

KB-Rapid-Fail Protection of IIS 6