早先我們觀察過WCF HTTP vs TCP的傳輸量差異,該測試呼叫GetData()作業傳入數字接回字串,並不算真的用到WCF的DataContract/DataMember序列化功能,故這次改聚焦在物件資料的序列化上,再做一次比較。

我小幅改寫Visual Studio WCF專案範本的CompositeType,增加一個IntValue。

    [DataContract]
    public class CompositeType
    {
        bool boolValue = true;
        string stringValue = "Hello ";
        int intValue = 1;
 
        [DataMember]
        public bool BoolValue
        {
            get { return boolValue; }
            set { boolValue = value; }
        }
 
        [DataMember]
        public string StringValue
        {
            get { return stringValue; }
            set { stringValue = value; }
        }
 
        [DataMember]
        public int IntValue
        {
            get { return intValue; }
            set { intValue = value; }
        }
    }

GetDataUsingDataContract()也做一點改寫,傳回值改成CompositeType[],傳回資料筆數由傳入的CompositeType.IntValue決定,藉此彈性控制傳回結果筆數,以觀察資料筆數多寡對資料量的影響。

        public CompositeType[] GetDataUsingDataContract(CompositeType composite)
        {
            if (composite == null)
            {
                throw new ArgumentNullException("composite");
            }
            var res = new List<CompositeType>();
            for (var i = 0; i < composite.IntValue; i++)
                res.Add(new CompositeType()
                {
                    BoolValue = composite.BoolValue,
                    StringValue = "Item" + i,
                    IntValue = i
                });
            return res.ToArray();
        }

Client端則修改如下,改呼叫GetDataUsingDataContract(),透過IntValue要求Server傳回1、16、64、128或256筆結果,取得結果後加總各筆資料的IntValue並檢視最後一筆的StringValue,簡單驗證資料正確性。

        static void Main(string[] args)
        {
            string[] bindingTypes = new string[] {
                "BasicHttpBinding_IService1",
                "NetTcpBinding_IService1"
            };
            foreach (var bindingType in bindingTypes)
            {
                var tsc = new WcfWas.Service1Client(bindingType);
                var compData = new WcfWas.CompositeType()
                {
                    BoolValue = true
                };
                var counts = new int[] {1, 16, 64, 128, 256};
                for (int i = 0; i < counts.Length; i++)
                {
                    compData.IntValue = counts[i];
                    var res = tsc.GetDataUsingDataContract(compData);
                    var sum = res.Sum(o => o.IntValue);
                    var txt = res.Last().StringValue;
                    Console.WriteLine("Items Count={0}, Sum={1}, String={2}", 
                        res.Length, sum, txt);
                }
            }
            Console.Read();
        }

執行結果如下,顯示內容沒什麼意義,期間的資料傳輸量才是重點。

Items Count=1, Sum=0, String=Item0
Items Count=16, Sum=120, String=Item15
Items Count=64, Sum=2016, String=Item63
Items Count=128, Sum=8128, String=Item127
Items Count=256, Sum=32640, String=Item255
Items Count=1, Sum=0, String=Item0
Items Count=16, Sum=120, String=Item15
Items Count=64, Sum=2016, String=Item63
Items Count=128, Sum=8128, String=Item127
Items Count=256, Sum=32640, String=Item255

所以我們開啟MNM,觀察HTTP及TCP傳輸的封包記錄如下。黃底部分是每次Server用來回傳結果的封包,旁邊已加註該次傳回資料筆數方便對照。

BasicHttpBinding

NetTcpBinding

整理結果如下,中間兩欄的數字為HTTP及TCP傳回不同結果筆數產生資料量(Bytes),最後一欄則為TCP資料量除以HTTP資料量的比例。

數字有點可疑,BasicHttpBinding使用XML序列化,NetTcpBinding採二進位序列化,但差距比想像的小很多,且筆數愈多,差距愈小,在256筆時,資料量比例約為10:8,與直覺出入甚大。莫非與HTTP壓縮有關?檢視封包內容,果然看到SOAP XML被IIS壓縮,實際上傳送的不是XML,而是被壓縮過看似亂碼的資料。

為觀察未壓縮的原始資料量,在IIS關閉動態內容壓縮:

重新測試一次,這回可在封包觀察到SOAP XML的模樣,很肥!

而用XML傳256筆資料要花35,118 bytes。

重新統計IIS未壓縮模式下的SOAP XML傳輸,除了單筆資料外,不管筆數多寡,TCP資料量固定維持SOAP XML的15%,符合我們的認知。

實務上,IIS會啟用動態壓縮,最後的實驗純屬好奇並非常態,第一次做的統計才接近真實狀況。也就是說,在IIS壓縮加持下,HTTP+SOAP XML的資料量膨脹不如想像嚴重(例如:256筆時僅多21%),但每次傳輸耗用較多封包數,資料量較大仍是事實,基於效能考量,Intranet的純Windows應用仍應優先考慮TCP。


Comments

Be the first to post a comment

Post a comment


94 - 64 =