代码

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml.Serialization;
using System.IO;

namespace SerializableTest
{
    class Programaa
    {
       
        public void SerializeDocument()
        {
            string filename = "e:\\books.xml";
            //　Creates　a　new　XmlSerializer.
            XmlSerializer s =
            new XmlSerializer(typeof(MyRootClass));

            //　Writing　the　file　requires　a　StreamWriter.
            TextWriter myWriter = new StreamWriter(filename);

            //　Creates　an　instance　of　the　class　to　serialize.　
            MyRootClass myRootClass = new MyRootClass();

            /*　Uses　a　more　advanced　method　of　creating　an　list:
         create　instances　of　the　Item　and　BookItem,　where　BookItem　
         is　derived　from　Item.　*/
            Item item1 = new Item();
            //　Sets　the　objects'　properties.
            item1.ItemName = "Widget1";
            item1.ItemCode = "w1";
            item1.ItemPrice = 231;
            item1.ItemQuantity = 3;

            BookItem bookItem = new BookItem();
            //　Sets　the　objects'　properties.
            bookItem.ItemCode = "w2";
            bookItem.ItemPrice = 123;
            bookItem.ItemQuantity = 7;
            bookItem.ISBN = "34982333";
            bookItem.Title = "Book　of　Widgets";
            bookItem.Author = "John　Smith";

            //　Sets　the　class's　Items　property　to　the　list.
            myRootClass.Items.Add(item1);
            myRootClass.Items.Add(bookItem);

            /*　Serializes　the　class,　writes　it　to　disk,　and　closes　
               the　TextWriter.　*/
            s.Serialize(myWriter, myRootClass);
            myWriter.Close();
        }

        public MyRootClass DeSerialize()
        {
            TextReader reader = new StreamReader("e:\\books.xml");
            XmlSerializer serializer =
           new XmlSerializer(typeof(MyRootClass));
            var myBooks = (MyRootClass)serializer.Deserialize(reader);
            reader.Close();
            return myBooks;
        }

    }

    //　This　is　the　class　that　will　be　serialized.
    [Serializable]
    public class MyRootClass
    {
        public MyRootClass()
        {
            items = new List<Item>();
        }

        private List<Item> items;

        [XmlArrayItem(ElementName = "Item",
   IsNullable = true,
   Type = typeof(Item)),
   XmlArrayItem(ElementName = "BookItem",
   IsNullable = true,
   Type = typeof(BookItem))]

        public List<Item> Items
        {
            get { return items; }
            set { items = value; }
        }
    }

    public class Item
    {
        [XmlElement(ElementName = "OrderItem")]
        public string ItemName;
        public string ItemCode;
        public decimal ItemPrice;
        public int ItemQuantity;
    }

    public class BookItem : Item
    {
        public string Title;
        public string Author;
        public string ISBN;
    }



}

http://tech.ddvip.com/2010-03/1268192963146672_3.html

本文介绍了 IBM Page Detailer 的功能和使用，并通过一个实例演示了如何对 IBM Page Detailer 获取的结果进行分析，并为 Web 应用性能改进提供建议。

介绍

在性能测试的日常工作中，测试人员经常需要一些工具为我们提供用以分析的数据。选择行之有效的工具，往往可以使测试工作事半功倍。在对 Web 应用性能的分析过程中，测试人员需要获取与网络传输相关的数据。对于底层信息的获取，许多已有的工具可提供数据包级别的数据。但当测试人员需要更进一步的数据进行分析时，这些工具提供的信息往往太过繁杂，给分析过程带来一定程度的不便。在这种情况下，我们推荐使用 IBM Page Detailer 来提高工作效率。

IBM Page Detailer 是由 IBM 研究院的两位资深工程师 LeRoy Krueger 和 Nat Mills 共同开发完成的。这是一款用来衡量 Web 应用性能的软件，由于是基于客户体验的角度设计，从而更有利于依据其收集的数据来调整 Web 应用的性能，更好地满足客户需求，达到更好的客户满意度。

IBM Page Detailer支持Windows® 2000, XP, Server 2003以及Windows Vista操作系统，分为Basic和Pro两个版本，其中Basic版本的安装文件可以在 IBM alphaWorks下载。

Basic 版属于免费体验版本，在功能上有一定的局限。而 Pro 版本则具有如下的加强功能：

• 对 HTTPS（SSL）通讯的全面支持
• 可以保存和导入获取数据
• 以 XML 的格式导出数据
• 标注功能
• 事件视图中文字处理的查找功能
• 图像显示功能

本文所有示例均以 Pro 版本为例，以下不再做特殊说明。

IBM Page Detailer 通过在客户端的 Windows 端口堆栈中插入探针（Probe）来获取相关信息。对于 Microsoft Internet Explorer，Mozilla Firefox 和部分 Netscape 浏览器，不需要配置即可自动激活探针。当使用其他类型的浏览器时，可通过修改安装目录下的 wd_WS2s.ini 文件来实现探针激活，具体的修改方法可以参照帮助文件中“Using Page Detailer with Other Applications”这一章节的内容。

IBM Page Detailer 能够获取以下类型的数据：

• 总连接时间
• 端口连接时间和传输数据量
• SSL 连接时间和传输数据量
• Server 响应时间和传输数据量
• 内容传输时间和数据量
• 传输延迟时间
• 请求字节头
• 请求传输数据
• 反馈字节头
• 反馈数据内容
• 页面数总计，平均及最大、最小页面数

IBM Page Detailer 提供了丰富的图例（参见 图 1），使用不同的颜色和图标代表不同的状态和元素，这令数据显示一目了然，方便了分析过程。

IBM Page Detailer提供了两种视图——图表视图和细节视图。在图表视图（参见 图 2）中，显示各个页面下载的时间，字节数，总的元素数，并且会依照实际的传输顺序用相应颜色的彩条表示各个元素的传输过程及在整个页面下载时间中所占的比例。其中重叠的部分表示这些元素的下载是并行完成的。

图表视图中从全局的角度展示了各个页面下载的概况，如果想了解页面中各个元素的详细信息，需要到细节视图中来查看。

细节视图（参见 图 3）中的默认列只显示元素名称、下载时间、元素大小以及元素下载过程图例。除此之外，可以通过点击右键（如 图 4 所示），选择增加列来在视图中显示更多需要的信息。这些信息是 IBM Page Detailer 在抓取数据的过程中自动收集，当选中所需列后就会立即显示相应的数据。

在两个视图中，通过鼠标双击元素所在行可以打开 Event 界面（参见 图 5），这里显示更多 http 请求的细节，可以帮助测试人员了解每个元素的全面信息。在此界面，还提供了查找和增加注释功能。

回页首

应用实例

环境描述

应用系统部署在 IBM WebSphere Portal Server 和 Process Server 上。并利用 IBM HTTP Server（IHS）进行图像文件的缓存，以期提高客户访问的效率，缩短响应时间。

• 在 IBM WebSphere Portal Server 上安装 IBM HTTP Server 并启用缓存。
• 使用 IBM Page Detailer 录制客户端第一次访问和后续访问同一页面的数据，针对数据进行比较和分析。

第一次访问数据结果

参看图6，从 Item Size 这一项可以看出，当第一次访问应用服务，所有的图像文件都被下载到客户端。

第二次访问数据结果

从 图 7 中可以看到，所有的图片没有再次下载，IBM HTTP Server 对图像文件的缓存发挥了作用。

进一步性能分析

我们对两次测试结果各个页面的响应时间进行了对比，发现在性能方面并没有明显的提高，应用中 Initiate domestic Page 页面在两次访问中都耗时最高。为此，我们对数据进行了进一步分析。

在 Initiate domestic Page 页面中，压缩 HTML 占用了绝大比例的传输时间，双击这个元素，打开 Event 窗口查看详细的 Http 请求信息。从 图 8 可以看出，时间主要消耗在 SSL server 的响应上，占据了总时间的 99.5% 左右。这里的 SSL server 响应时间从客户端发出请求开始计算，直至受到服务器端第一个返回数据包为止。

对于 IBM HTTP Server 图像缓存并没有明显改善性能的问题，我们也从数据对比中发现了原因。虽然应用系统中的一些页面图片元素较多，但是由于图片的字节数太小，在客户端和服务器端传输的时间也很短（参见 图 9）。所以 IBM HTTP Server 提供的图像缓存没有大幅度的提高访问性能。

在对其他页面（参见 图 10）的分析中我们发现，在向服务器端发送等量请求信息的条件下，一些页面的 SSL server 响应时间较短，所以对于 Initiate domestic Page 页面响应时间较长的问题建议开发人员对这部分代码进行走查改进，以求获得性能上的提高。

此外，通过对数据的分析，还发现对于各个页面的图片文件，都采用了 SSL 协议进行传输。由于图片本身并不包含需要保护的信息，所以采用 SSL 协议进行传输会在一定程度上增加传输负载，建议对图片不用加密形式传输。

回页首

总结

综合总体看来，作为一款基于用户使用角度开发的工具，IBM Page Detailer 能够帮助测试者掌握有关 Web 应用性能方面的大量数据，便于对性能问题进行分析，是 Web 应用性能测试中不可或缺的工具。

 from:http://www.ibm.com/developerworks/cn/web/wa-lo-pagedetailer/

This is a historic document and is not accurate anymore. For up-to-date details on the HTTP specification, see the latest HTTP/1.1 drafts

Status codes

The values of the numeric status code to HTTP requests are as follows. The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information.

Success 2xx

These codes indicate success. The body section if present is the object returned by the request. It is a MIME format object. It is in MIME format, and may only be in text/plain, text/html or one fo the formats specified as acceptable in the request.

OK 200

The request was fulfilled.

CREATED 201

Following a POST command, this indicates success, but the textual part of the response line indicates the URI by which the newly created document should be known.

Accepted 202

The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. there is no facility for status returns from asynchronous operations such as this.

Partial Information 203

When received in the response to a GET command, this indicates that the returned metainformation is not a definitive set of the object from a server with a copy of the object, but is from a private overlaid web. This may include annotation information about the object, for example.

No Response 204

Server has received the request but there is no information to send back, and the client should stay in the same document view. This is mainly to allow input for scripts without changing the document at the same time.

Error 4xx, 5xx

The 4xx codes are intended for cases in which the client seems to have erred, and the 5xx codes for the cases in which the server is aware that the server has erred. It is impossible to distinguish these cases in general, so the difference is only informational.

The body section may contain a document describing the error in human readable form. The document is in MIME format, and may only be in text/plain, text/html or one for the formats specified as acceptable in the request.

Bad request 400

The request had bad syntax or was inherently impossible to be satisfied.

Unauthorized 401

The parameter to this message gives a specification of authorization schemes which are acceptable. The client should retry the request with a suitable Authorization header.

PaymentRequired 402

The parameter to this message gives a specification of charging schemes acceptable. The client may retry the request with a suitable ChargeTo header.

Forbidden 403

The request is for something forbidden. Authorization will not help.

Not found 404

The server has not found anything matching the URI given

Internal Error 500

The server encountered an unexpected condition which prevented it from fulfilling the request.

Not implemented 501

The server does not support the facility required.

Service temporarily overloaded 502 (TO BE DISCUSSED)

The server cannot process the request due to a high load (whether HTTP servicing or other requests). The implication is that this is a temporary condition which maybe alleviated at other times.

Gateway timeout 503 (TO BE DISCUSSED)

This is equivalent to Internal Error 500, but in the case of a server which is in turn accessing some other service, this indicates that the respose from the other service did not return within a time that the gateway was prepared to wait. As from the point of view of the clientand the HTTP transaction the other service is hidden within the server, this maybe treated identically to Internal error 500, but has more diagnostic value.

Note: The 502 and 503 codes are new and for discussion, September 19, 1994

Redirection 3xx

The codes in this section indicate action to be taken (normally automatically) by the client in order to fulfill the request.

Moved 301

The data requested has been assigned a new URI, the change is permanent. (N.B. this is an optimisation, which must, pragmatically, be included in this definition. Browsers with link editing capabiliy should automatically relink to the new reference, where possible)

The response contains one or more header lines of the form

       URI: <url> String CrLf

Which specify alternative addresses for the object in question. The String is an optional comment field. If the response is to indicate a set of variants which each correspond to the requested URI, then the multipart/alternative wrapping may be used to distinguish different sets

Found 302

The data requested actually resides under a different URL, however, the redirection may be altered on occasion (when making links to these kinds of document, the browser should default to using the Udi of the redirection document, but have the option of linking to the final document) as for "Forward".

The response format is the same as for Moved .

Method 303

	Method: <method> <url>
	body-section

Note: This status code is to be specified in more detail. For the moment it is for discussion only.

Like the found response, this suggests that the client go try another network address. In this case, a different method may be used too, rather than GET.

The body-section contains the parameters to be used for the method. This allows a document to be a pointer to a complex query operation.

The body may be preceded by the following additional fields as listed.

Not Modified 304

If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.

Response headers are as if the client had sent a HEAD request, but limited to only those headers which make sense in this context. This means only headers that are relevant to cache managers and which may have changed independently of the document's Last-Modified date. Examples include Date , Server and Expires .

The purpose of this feature is to allow efficient updates of local cache information (including relevant metainformation) without requiring the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET) and minimizing the transmittal of information already known by the requesting client (usually a caching proxy).