ASP.NET Web应用程序中数据绑定的可扩展性外文翻译资料

英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料

ASP.NET Web应用程序中数据绑定的可扩展性

TONI STOJANOVSKI, IVAN VELINOV, MARKO VUČKOVIK

摘要：ASP.NET web应用程序通常使用服务器控件来提供动态网页，数据绑定服务器控件来显示和维护数据库控件。大多数开发人员开发web应用程序时会使用ASP.NET服务器控件的默认属性，这种应用程序能够允许并行应用程序的快速开发。然而，创建一个高性能，多用户，可扩展的web应用程序需要使用特定代码服务器控件的提高。在这个实证研究中，我们评估了多种使用分页和排序数据驱动技术的影响在web应用程序中：在web服务器上web服务器控件的自动数据分页和排序；在数据库服务器上的分页和排序；索引和非索引数据库列；群集与非群集索引。我们发现，当自定义分页是基于SQL存储过程并使用群集索引时性能显著提升。我们已经应用的分页和排序存储过程的方法是来自微软提供的基于ASP.NET成员的SQL Server。当使用我们的方法时执行时间缩小2.7倍。使用合适的群集索引时，执行时间可减少到3倍和11倍之间取决于表中记录的数量。

关键词：web应用程序；可扩展性；数据库访问；数据绑定

1.引言

在过去十年，我们观察了web应用程序使用的增加。这是许多因素的结果：零客户安装，服务器部署，功能强大的开发工具，用户群的增长等等。竞争那个，快速的变化和用户需求的增长使得web应用程序的快速发展。Microsoft Visual Studio (MVS)是今天web应用程序发展的主流环境。MVS提供了许多机制以支持ASP.NET应用程序的快速开发。大多数开发者更倾向于使用ASP.NET服务器控件的默认设置，可以说其促使web应用程序的快速发展具有重要的意义。虽然ASP.NET服务器控件可以显著降低应用程序的时间到市场，但同时他们可以减少web应用程序的性能和可扩展性。影响web应用程序响应时间的因素分析是研究[1][2]的一个活跃领域。在本文中，我们证明向ASP.NET服务器控件添加自定义程序逻辑能提高web应用程序的性能和可扩展性。这里我们着重描述数据绑定机制，这种机制被用来维护和显示来自数据库的数据在web应用程序中。其他机制，如数据更新，页面缓存，数据缓存，状态管理等，这都是为今后工作奠定的。

在这里我们解决以下研究问题：(i)分页机制对响应时间的影响是什么？(ii)能否自定义存储过程来获取，排序，分页以提供更好的响应时间并提高可扩展性，相比ASP.NET服务器控件的自动数据绑定(ADB)？(iii)分页和排序结果时，对响应时间的指数影响是什么？(iv)在数据库记录中响应时间依赖什么？(v)在那些方案时最好使用ASP.NET服务器控件？在读取，排序和分页时，什么时候可以更好的使用自定义存储过程？

我们的论文大纲如下所示。在第二节我们解释ASP.NET应用程序数据绑定中，如何应用分页，排序，显示数据的基础知识。第三节描述我们测试环境和测试方法。测试环境被用来衡量ASP.NET页面的响应时间。这写页面是用各种方法获取和显示的。在第四节中，我们展示和解释测试的结果。第五节应用我们的方法进行排序和分页由微软提供的SqlMembershipProvider，来达到性能的显著提高。第六节总结全文。

2.web应用程序的数据绑定

当我们使用ASP.NET的数据绑定控件时，例如GridView来显示来自数据库中控件，最简单的方法是将数据绑定控件与数据源控件链接到数据库并执行查询。使用这种情况时，数据源控件能自动的获取来自数据库服务器的数据在页面的生命周期内Page.PreRender 事件之后。

此代码被用于数据源控件和数据库绑定：

在数据绑定控件中显示数据的另一种方法是在Page.load事件中得到数据，将其存储在一个数据集对象中，然后将数据绑定控件绑定到数据集。里面的数据绑定控件进行分页和排序。我们没有观察到在执行时的任何不同在这两种情况中，由于慢响应时间（大量的数据传输，没有使用数据库索引等）的原因导致这两种方案的差异。

在web页面中显示记录数，这是一个常见的做法来显示有限的记录数(记录页)并允许用户浏览页面的记录，即以使用数据分页。数据绑定控件如GridView以为排序和分页建立了一个内置的机制。首先，数据源控件从数据库中获取所有的数据(见代码1)在一个数据集，然后ASP.NET数据绑定控件负责对数据集进行排序，并显示少量的足以填满页面的数据记录。例如，一个数据集可以包含数以百万的记录，但是一个页面只显示这个记录的十分之一。这个方法会带来两个问题：(i)在数据库服务器和web服务器间有大量的数据传送，在多服务器发展情况中这是一个和重要的问题；(ii)CPU和内存资源消耗的显著问题在对web服务器上的大型数据集进行排序时。显然，这些问题已经产生了负面的影响在web应用程序的性能和可扩展性上。减少网络数据的发送量可以减缓这些问题，还能减少资源的消耗。一个人需要编写一个自定义的SQL存储过程对记录进行排序，并且这些记录只显示在web页面中。因此，网络消耗减少，并且数据库服务器获得排序分页记录的能力。这有几种方法来执行分页和排序的存储过程。我们使用以下之一：此存储过程逻辑上把testTable表格划分页大小为@pageSize的页面，并从@pageNumber页返回记录。记录被ID字段排序。此存储过程的性能很大程度上取决于ID字段的类型和索引类型的使用：群集和非群集。通过使用索引的数据结构我们可以显著提高获取数据库中的数据所需要的时间。

在我们的测试环境中，我们测试了以下几个参数在不同的情况下：(i)数据库中的记录数;(ii)使用群集和非群集的数据库索引；(iii)在ASP.NET数据库服务器控件的自动数据排序和分页和在SQL存储过程的分页和排序；(iv)不同的部署方案。

基于前面参数的方案将在我们的测试环境中测试。

3.测试方法

对于我们的测试环境，我们使用的计算机有以下特性：Intel 核心 2 双核 CPU 2.00 GB RAM;Windows 7专业32位;互联网信息服务 (IIS) 版本 7.5.7600.16385;Visual Studio 2010 极限;SQL Server 2008 Express （使用只有 1 GB RAM）。

为测试环境我们创建了一个带有两个web页面的web应用程序——一个用于数据绑定，分页，排序，如第二节所叙述的。每个Web页面使用不同的机制来绑定GridView控件显示从数据库中返回的数据并排序，分页数据。第一页使用ADB,并包含一个允许分页和排序的GridView控件。这个控件是一个从数据库获取所有记录的存储过程如代码1。第二页使用自定义存储过程(见代码2)查询结果。该存储过程在SQL服务器上对记录进行排序，并返回的记录只显示在GridView控制的web页面上。

测试数据库有一个名为testTable的表，这个表有五个领域。用随机值填充表中的记录。

排序字段和页号被传递给web页面在查询字符HTTP的请求下。我们还创建了一个发送HTTP请求到IIS web服务器的windows应用程序。为HTTP请求的查询字符串包含了一个随机页号和排序字段。通过HTTP请求的页面从一个SQL Server表查询数据。我们感兴趣的是在web服务器上处理HTTP请求所需要的时间。我们使用ASP.NET跟踪来确定发生在页面生存之前的事件，就是，页面处理过程的起点和终点。在Page_Init事件处开始计时，在Page_SaveComplete事件处结束，也就是在Page_PreRender事件之后。Web页面负责记录一个文本文件的响应时间，并分析了这些时间测量。

4.主要结果

图二和图三我们展示了当这两个web页面内数据表有1000000个记录时的请求时间。这两个web页面有三种类型的结果，他们中每个字段都被用来排序记录。同时，testTable表没有索引。每个web页面和相应的排序和分页都被测试500次。实测的响应时间被分为一个大约有10个数目的箱中。本节给出的数据显示了箱的频率。箱被用线链接的标记的表示。所有箱值的总和在曲线内为500。

图2显示了使用ADB的ASP.NET页面在执行数据排序和分页时的结果。这种方法的主要问题是数据源控件需要从数据库中获取1000000个记录在ASP.NET能够排序结果之前。ID字段自动增加，并记录数据库中字段的物理排序。因此，为ASP.NET选择通过ID字段数据集的时间比其他的两种选择更快。TextField和IntField的排序响应时间是不同的，因为选择整数比文本字段更快。

图三显示了在使用SQL存储过程的数据中进行选择和排序的结果如代码2.读者应该注意到图三使用一个来自图2的不同的时间尺度。响应时间同ADB比较明显缩短。原因有两个：(i)SQL服务器优先工作于大型数据集例如排序和筛选；(ii)SQL存储过程返回ASP.NET页面仅需要一小部分记录就足以填满整个页面。不同列排序造成的响应时间不同是由图二所解释的相同的原因引起的。接下来，在testTable索引下我们重复上述测试。这样做的主要目的是能够看到响应时间的不同差异当群集和非群集索引被使用时。

在图4中，testTable表被ID集群并且字段和文本字段没有群集索引。由于群集索引，通过ID排序和分页的选择时间比通过IntField和TextField选择和排序的时间小。这种模式在图5和图6中重复出现：通过群集索引的响应时间明显小于通过非群集索引的响应时间。

比较图4，图5，图6.图3更明显，在使用群集和非群集索引中的任意一个都能够显著改善在数据获取的时间需求中。指数的存在对响应时间没有任何的影响当在使用web服务器的ASP.NET的web页面做排序和分页时。结果是相同的，如图2所示。

第二个select语句” SELECT * FROM testTable WHERE ID gt; @LastID ORDER BY ID ASC”在代码2中有一个缺点，是其在运行时间和内存消耗有一些消极的影响。@pageNumber的值越小@LastID的值也越小。因此，select语句需要排序并返回一个较大的数据集，且也需要增加他的运行时间。SQL Server使用索引文件来识别记录的排序，然后加入带有testTable表中记录的索引文件，最后返回记录中的每一列(注意带有*符号的，这意味着表中的所有列都要返回)。随着数据集大小的增加，SQL Server使用更多的内存排序数据集。因此，对于页面索引较小的select语句运行速度较慢且占用更多的内存。

图3-6的特殊性是其两个峰值的存在。他们做了选择排序在非群集索引文件(图3中的所有文件)，或者是在非群集索引的字段中(图4的IntField和TextField，图5的ID和IntField，图6的ID和TextField)。这意味着在代码2中有两个不同SQL存储过程的响应时间。我们检测到的响应时间要比输入@pageNumberlt;18000参数的时间长。如果数据集消耗的内存多于SQL Server存储过程可用的，SQL Server会开始使用过多慢于RAM的虚拟内存。在我们的测试环境中，SQL Server会在数据集中的记录数大于820000(第一个带有10个记录的18000页面会被跳过)时使用虚拟内存。对于这两种情况，排序在非索引字段或带有非群集索引的字段中，上述说法是成立的。然而，当排序是由非群集索引字段进行(图4的ID，图5的TextField，图6的IntField)则存在一个峰值。表中的记录已经被群集索引字段排序。

我们重复测量了不同数目表中的记录：100000,200000,500000和1000000记录。这样做的目的是测试在记录数中响应时间的依赖性。正如预期的那样，响应时间的增长与数据库中的记录数成正比。响应时间会增长的更快在ASP.NET的排序和分页同SQL Server 的排序和分页相比较。图7-图10展示了响应时间平均500的测试和testTable中的记录数的相关性。最快的响应时间和表中的记录数增长的最慢时是其使用带有群集索引的SQL存储过程，这个过程先用一个带有非群集索引的SQL存储过程，然后在用没有索引的SQL存储过程，其次是通过web服务器的排序和分页实现的，即ADB。其他的响应时间的关系如图2-图6所示已保存所有测试的记录数。

值得一提的是如图11所展示的唯一区别。当表中的记录数较小时(例如500000)并且群集索引是TextField，只有一组响应时间是按ID和IntField排序的，因为内存消耗的足够小时是不会出发虚拟内存的使用。此外，按ID和IneField排序500000的记录时的响应时间小于图5的1000000记录的响应时间。

以上提及的测试都在一个分布式的部署方案重复实现：MS SQL被安装在一个物理服务器上，且IIS服务器被安装在另一个服务器上。当在web服务器上排序和分页时，我们观察到响应时间的快速增长取决于网络速度由于大量的数据是运行在网络上的。

对于大量的数据库记录，基于分页的ADB优先于基于SQL存储过程的分页。这两个单服务器的部署和分布式部署是有效的，并所有的字段都带有群集索引，非群集索引或者是没有索引。ADB的唯一优势是能够快速开发应用程序。当需要快速的响应时间和稳定性时，只有当数据库中记录的数量在100-200之间ADB才能够被使用。

4.1 SQL排序和分页的改善

代码2的第二个select语句的问题，如第4节所述，可以通过存储过程的改善解决。程序：

“select *”从代码2分为两个部分：第一部分通过索引字段和存储的记录只能排序到一个临时表#t中。只有@PageSize记录能够被存储。没有加入到[int]字段的索引和testTable表中记录之间的，其执行时间对第一部分来说非常短

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[30437]，资料为PDF文档或Word文档，PDF文档可免费转换为Word