摘要: 描述了Ameripay公司参照“如何在.Net应用程序中对记录进行分页”一文实现提高应用程序性能的过程，“如何在.Net应用程序中对记录进行分页”是Microsoft模式&实践一书中关于提高.NET应用程序性能和可扩展性的章节。
背景
我曾经为全球排名前2000的公司开发Web应用程序，所以编写的软件必须能够支持50,000到100,000的雇员，毕竟，每个公司都应为他们的应用程序负责。我现在在Ameripay从事的薪水和人力资源应用程序使用了ASP模型并且被部署在我们的主办公室里，作为服务端为我们的所有客户服务。
我们定位于中小公司，因为如果客户数目超过2000，性能上就会有额外的压力。含有10到100行的典型小列表(由于所有行均被放入数据库中的一个块中，即使在表扫描情况下性能开销也很小，所以不需要索引) 会产生一个有20,000到200,000行的表(这在表扫描情况下会导致明显的延迟)。平均有1000个条目的列表在数据库中则会产生有2百万行的表。像薪水支票这类条目—我们每月会产生约25万薪水支票，但是每个支票也许附带有10份收入和扣除款项—这样每个月数据库里就会产生数百万行。
我在我的性能和可测性计划里要提到的最后一点是我们持续的快速增长率。在过去的8年里，我们平均增长率超过了750%，使我们在过去的两年里一直是成长最快的私营公司。一年前我开始的时候，我们有1,500 个客户公司，今天我们有2000个，并且在继续增长。2005年一月我们创造了新客户数目的新记录。所以当我设计系统时,必须使其在不久的将来能够适应以下情况:即客户增长幅度为5,000到10,000。
考虑到这些通常关注的情况，这就需要我尽一切可能来优化性能—这就是为什么我发现Microsoft 模式& 实践 一书中的提高 .NET 应用程序性能和可测量性是这么的有用。
把记录分页
带着这个背景，我决定尽可能地使所有结果集合的规模保持为最小值，因此在整个应用程序中我们都贯彻了分页的概念。我们的代码来自于主题为如何: 在.NET 应用程序中对记录进行分页一文提供的示例代码。
我们已经在这个如何让中扩充了示例代码,这样它就能适用于四种非常不同的情况：
• 用于小列表的简单分页控件。小列表典型代表就是我们定义过的对每个公司所含条目数少于100行的列表。
• 分页下拉组合框。当你使用下拉框,但由于下拉框所含条目数目可能超过100行,这样所包含的每条记录都会使页面变大并增加网络传输的开销,这时你就需要使用分页下拉组合框。
• 有了分页,可使中到大型的列表(中等是指每个公司有100到1000行,1000以上为大型)拥有更加复杂的过滤搜索能力)—包括拥有数千万行的表。
• 一个高级分页控件，它像一个浏览控件条一样，允许用户输入字符，并基于下拉框中指定的排序方法或选定项,来查找下一个匹配项。它使用了 XML HTTP 来回发页面的小数据集，并动态更新控件，而无需重画整个页面。
引人注目的是，我们的基础分页存储过程处理这四种情况都会花费异常的时间。这个存储过程来自于Microsoft 模式 &实践 中的app_temp 这个例子 (这里我们已经扩充了这个例子,支持了升降排序,并可以用不同的搜索标准在不同的表上做相同的搜索)。
简单分页控件
对小列表，我们创建了一个简单的分页控件，它允许你能选定指定页码的页，或者点击某些箭头来显示下一页，或下面几页，或直接跳至最后几页。
包含此控件和添加它一样简单：
<Escher:Paging id="paging" PageId="coSetup.coPositions"
HidePaginationForSinglePageResults="True"
runat="server"></Escher:Paging>
然后调用一通用存储过程(跟app_temp 过程示例相像,但是我们的这个是动态的，因此能用于多个表) 来获取行数，页面和所需页面关联的数据集。我们基于用户屏幕的分辨率来计算每页返回的行数。
图1
如果需要，结果只有一页时，控件可以隐藏VCR 按钮。
分页下拉组合框
每个页面所含数据的数量很大程度上影响其在互联网上的下载时间，特别是在一些用户仍然通过56K 调制解调器拨号上网的情况下。虽然下拉框可以方便地为用户提供可供选择的条目，但是当你有特别多的下拉框时，页面数据量就会变得很大。对中到大型列表，我们创建了分页的下拉组合框，它只显示匹配的记录。
默认情况下，会显示所有匹配和一个简单分页控件。
图2
但是在用户在文本域进行输入后，只有匹配的记录才会被显示。比如输入S 将显示所有名字以S开头的雇员的列表，如下所示。
图3
当用户输入更多字母时，我们会用匹配的记录重画列表：
图4
分页过滤搜索
要在一中到大型列表中找到某条记录，我们可以使用户能基于最相关字段来过滤数据。这种过滤查询可用于公司、雇员、发票列表等。实际结果将依赖于搜索中输入的搜索标准并会根据选定的列头进行排序，并且可以包含通配符; 比如，用户能通过输入S来找到姓以S开头的名字或者输入%S来找到含有字母S的名字。它是跨字段累计的，因此，举个例子来说，你能找到姓以S开头并报告到雇员119的人。
图5
分页浏览控件条
虽然分页的搜索列表页极大方便了查找记录，但用户也许不喜欢每次都要返回到列表来搜索其它匹配。因此我们把头三个优先考虑的条目一起放入到一个分页浏览控件条里，如下表所示。
图6
当搜索后一或前一个记录时，你可以选择不同的排序标准(名字，ID，部门等)来决定记录的显示顺序。下拉框的排序能让你应用在过滤搜索页面上输入的过滤标准，以限制哪些雇员被显示。比如，如果你指定雇员的部门为软件开发部，则只有那个部门的成员会在浏览器中显示.控件中间的下拉框能让你通过输入字符串来搜索指定的记录。比如,输入S将找到首个匹配。
图7
输入Sc将找到下一个匹配，等等。
图8
基于你选定得排序方式(名字,ID,部门等),你可以通过列排序的方式浏览匹配的列表。当显示不下所有的匹配时,用户可以点击更多按钮.所有这些都被一XML HTTP 界面管理,因此不必重画整个页面(直到你选定一个记录并浏览到那条记录)。
图9
结论
通过在应用程序中扩展分页的概念，我们能够极大减少服务器和客户端之间的数据流量.这就帮助我们有效地提高了性能。
自从我接任Ameripay软件开发部主管,我们重写了我们的体系,因为先前的系统没有效率。我们的IT 人员已经报告说我们的服务器CPU使用率大大降低了。更重要的是，同时运行新老系统的用户都报告说有10到100倍的性能改善。我们使我们最大客户的一些以前经常引起超时的操作现在会在10秒以内得到响应。
