WCF的配置参数maxItemsInObjectGraph所引发的的问题

无论测试什么系统，对于数据表的容量测试都是一个比较重要的环节，这里有两个需重点关注的点：
1、当单表的数据达到一定程度时，页面的加载时间是否能接受
2、当单表的数据达到一定程度时，涉及该表的相关功能是否正常

自己最近在做该方面测试的时候，发现了一个问题，问题如下：
问题描述：当班级表的记录数不小于6554条时，学生管理界面加载失败

提交该问题后，开发花了很久的时间，仍找不出代码里有任何问题后，回复“测试环境问题”，为了证实该问题不是测试环境所导致，自己就仔细的分析，设计相应的分析方案，如下：
1、由于该系统较简单，BS架构，因此初步判断问题可能出在以下两个方面，即IIS或数据库
2、分布排查
第一步：先检查是否是IIS问题：从问题环境中隔离出IIS（使之连接正常环境的数据库）进行测试一切正常，可以断定IIS并无问题
第二步：于是可以确定问题出在数据库部分了。数据库问题先从数据结构开始分析，与正常环境的数据库进行对比，正常
第三步：分析问题库与正常数据库差别，发现问题库存在大背景数据。应该是由此产生的问题。
第四步：锁定具体问题表。通过分析以及与开发人员讨论的方式，了解登录系统后页面马上加载两张数据库表。
第五步：尝试减少目标数据库表中数据，最终测试出班级表存在问题，并确定出异常数据量边界值。

问题原因：WCF的配置参数maxItemsInObjectGraph超过默认值65535导致
在用WebService序列化的过程中，序列化的对象个数超出了65535个，也就是maxItemsInObjectGraph的默认这，造成这用情况是因为客户端与WebService之间传递的是对象，而WebService每次都要序列化对象，所以对序列化的对象的个数是有限制的，默认的就是65535,这个对象的个数是怎么计算出来的呢？

例如:现在在WebService端有一个对象Student

Public class Student

{
     Public int ID{get;set;}

    public Name{get;set;}

}

在传递的过程中，对象的个数就是这个对象的本身加上本身所包含的对象的个数,就这个来说那么就是3个对象，要想使这三个对象能够序列化 maxItemsInObjectGraph=对象个数+2(假设maxItemsInObjectGraph默认值为0)，只有在maxitemslnObjectGraph 比对象个数+2大的情况下，编译器才不会报错,要不然,就会出现上面的错误，其实还不止于此,这个的前提是只有一条记录的情况下，如果是两条记录呢,MaxItemSlnObjectGraph的最小值=对象个数*记录的条数(传递的可能是这个对象的一个集合)+2，也就是传递的数据越多，MaxItemSlnObjectGraph的值就会越大，当超过他的默认值(65535)的时候就会出现上面的错误

讲到这，解决方法也就简单了，修改MaxItemSlnObjectGraph的值