项目测试中，客户向我们反应，某个页面请求速度特别慢，简直无法忍受。这里简单插一些情况的描述：对于一个使用人数、并发操作并不多的项目，客户不会过多的在性能上提出要求，对他们来说，多几百ms的等待时间，不会带来更多情绪。

    但是，当你请求某个页面后，去泡杯茶回来，发现页面还死死的在那里，进度条不紧不慢的一点一点增长，就无法忍受了。利用Firefox的debug测了一下，平均请求时间19s左右，而光import那个页面所需要的时间就是18s多，问题肯定出在页面上。

    那个页面是被IFreame包含进来的，包含5个TextBox、4个DropdownList、3个CheckBox、3个Button（作为分页的查询条件），下面就是分页的DataGrid（每页10条数据）。我注意到其中有一个DropdownList的ListItem有200多项，查了一下Response，发现viewstate黑压压一块。显然，这也是影响性能的一个原因。

    在跟客户商量后，将这个DropdownList改成了TextBox，做成模糊查询。恩，速度到了15s左右，快了3到4秒。这样的改善已经是很不错的成绩了，但是我们还要等待15s，显然无法让客户满意。

    这下问题就不明显了，我禁用了viewstate，发现并没有多少效果。页面数据量也不是很大啊，几个DropdownList的初始化，分页的实现是利用存储过程，在服务器数据库中，利用游标取记录条数。传递过来，也仅仅是10条而已。

    查看页面源代码发现N长的JS，是不是问题出在加载日期控件上呢？我将日期控件屏蔽了，再测，问题依旧，还是15s！！

    感觉有点束手了，测试其他页面，没有问题，响应速度很理想，甚至是一些控件N多的页面。

    不经意间点分页的“下一页”，恩，时间很漫长！可是我下一页的操作，只读取了下一个10条数据啊！我在服务器查询分析器下测试了存储过程，反应没问题。那问题应该是出在DataGrid的绑定了，这时候，我注意到，datagird中包含不少模板列，其中有不少LinkButton，涉及到显示不显示的逻辑操作，例如：

 

    顿时，有了个想法，会不会是触发ItemDataBind事件，遍历表格控件时，消耗系统资源呢？

    将这部分功能屏蔽，果然！效果理想，响应时间到了3s左右，速度差强人意。我暗舒口气......

    总结：

    viewstate利弊共存，怎么使用，值得权衡。有时候，没有办法，不妨跟客户沟通一下，变换一些实现方法。

    永远不要在ItemDataBind时，做太多事情。不妨，将数据处理放在数据库（视图、存储过程）、或者是在绑定之前，写方法处理。

    性能永远是一个隐形的需求，而我在这方面经验匮乏。尤其是，目前的项目规模小，那些在code时，留下的挥霍内存的变量声明、占用CPU的循环、遍历算法的行为随处可见。现在，我们能做的，就是在意识到这些后，一点点的改变这些习惯把。