ImageVerifierCode 换一换
格式:DOC , 页数:10 ,大小:656KB ,
资源ID:1253131      下载积分:20 文钱
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,省得不是一点点
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.wenke99.com/d-1253131.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: QQ登录   微博登录 

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ASP.NET 网页应用程序数据绑定的可扩展性.doc)为本站会员(滴答)主动上传,文客久久仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知文客久久(发送邮件至hr@wenke99.com或直接QQ联系客服),我们立即给予删除!

ASP.NET 网页应用程序数据绑定的可扩展性.doc

1、ASP.NET 网页应用程序数据绑定的可扩展性1ASP.NET 网页应用程序数据绑定的可扩展性摘要ASP.NET 网络应用程序通常用服务器控件来提供动态网页,用数据绑定服务器控件来显示和维护数据库。在开发网络应用程序的时候,大多数开发人员都使用ASP.NET 的默认属性,这就促进了可操作应用程序的快速发展。然而,创建一个高性能、多用户、可扩展的网络应用程序需要用定制代码来增强服务器控件。在这项实证研究中,我们评估了分页排序功能在数据驱动的 ASP.NET 网络应用的各种技术途径的影响:网络服务器的自动数据分页和排序;数据库服务器的分页和排序;索引和非索引数据库列;聚集与非聚集索引。自定义分页时

2、使用基于 SQL 存储过程和聚集索引,我们观察到了显著的性能改进。关键词:网络应用程序;可扩展性;数据库访问一、引言在过去的十年中,我们观察到网络应用程序一直在增加。这是一个很多因素的结果:零客户端安装,服务器只部署,强大的开发工具,不断增长的用户基础等。此外,竞争和快速变化且不断增长的用户需求,创建了一个网络应用快速发展的需2012 年 8 月 10 日收到手稿。 欧洲大学,信息技术学院,托妮托亚诺夫斯基,bld.Kliment Ohridski 68, 1000 Skopje, Macedonia。 (电话:+ 389 78 396 693,电子邮件:toni.stojanovskieur

3、m.edu.mk) 欧洲大学,信息技术学,伊凡沃立诺夫,bld Kliment Ohridski 68, 1000 Skopje, Macedonia。 (电子邮件:velinov.ivanlive.eurm.edu.mk) 欧洲大学,信息技术学院,Marko Vukovi,bld Kliment Ohridski 68, 1000 Skopje, Macedonia。 (电子邮件: vuckovik.markolive.eurm.edu.mk) 求。Microsoft Visual Studio (MVS)是现在主要的网络应用程序开发环境。MVS 提供ASP.NET 服务器控件的默认设置,这

4、是快速发展的最重要的推动因素。虽然了许多机制来支持 ASP.NET 应用程序的快速开发。大多数开发商倾向于使用 ASP.NET 的服务器控件可以大大减少应用程序的“上市时间” ,同时可以降低网络应用的性能和可扩展性。影响网络应用的响应时间这一因素分析是一个活跃的研究领域 1。在本文中,我们展示了给 ASP.NET 服务器控件的数据绑定机制添加自定义程序逻辑的重要性,换句话说,用于维护和显示数据的机制可以提高网络应用程序的性能和可伸缩性。在这里,我们解决以下几个问题:(一)相对于 ASP.NET 服务器控件的自动数据绑定,自定义的存储过程可以为获取、排序和分页的结果提供了更好的响应时间和改善的可

5、扩展性吗?(二)在排序和分页这些结果时,哪些是响应时间的影响索引?(三)在数据库记录的数字上,响应时间的依赖是什么?我们的文章概要如下。在第二节中,我们解释了 ASP.NET 应用程序中数据绑定、分页和排序的基础。第三节介绍了我们的测试环境和测试方法。测试环境是用来衡量ASP.NET 的页面响应时间,这实现数据的获取和显示的各种方法。在第四节中,我们解释了测试的结果。第五部分总结本文,并概述了进一步的研究。二、在 ASP.NET 应用程序中的数据绑定使用 ASP.NET 的数据绑定控件,如 GridView 控件,去显示数据库中的数据时,最简单的方法是用一个数据源控件来绑定数据绑定控件,用它连

6、接到数据库并执行查询。在这种使用情况下,数据源控件在页面生命周期 3的 page.prerender 事件后,自动获取数据从数据库服务器 2,并将其显示在数据绑定控件中。这是用于将数据源控件与数据库绑定的代码。“SelectCommand=“usp_autoDataBinding“ selectCommandType=“usp_autoDataBinding“/下面的代码是用一个数据源控件连接一个 GridView 控件。下面的存储过程是用于从数据库查询数据的。CREATE PROCEDURE dbo.usp_autoDataBinding ASBEGINSELECT * FROM testa

7、bleEND代码 1 返回数据库中的所有数据查询当有许多记录显示在网页中时,有一种常见的做法,就是只显示有限数量的记录(一页记录) ,并允许用户浏览通过记录的页面,即使用“数据分页” 。数据绑定控件,如 GridView 控件,有一个内置的机制是用于排序和分页的 2。首先,数据源控件从数据库中获取所有数据(见代码 1)到一个数据集中,然后,ASP.NET 的数据绑定控件负责排序数据集而且只显示足以填满一页的一小部分的记录。例如,一个数据集可以包含数以百万计的记录,但是一个网页显示这些记录中只有十分之一。这种方法带来的问题:(一)数据库服务器和网络服务器之间的大量数据,尤其是多服务器部署方案中的

8、问题;(二)在网络服务器上进行大型数据集的排序,会显著的消耗处理器和内存资源。显然,这些问题对应用程序的性能和可伸缩性有显著的负面影响。我们希望这些问题可以通过使用自定义的 SQL 存储过程而减少,SQL 存储过程可以排序并只返回将在网页上显示的记录。这样,网络的消耗就可以减少,而且数据库服务器就可以起到排序和分页这些记录的作用。我们使用下面的一个存储过程来进行分页和排序这些记录:CREATE PROCEDURE dbo.usp_selectGridViewOrderByIDpageNumber int, PageSize int = 10ASDECLARE Ignore intDECLARE

9、 LastID intIF pageNumber 1BEGINSET Ignore = PageSize * pageNumberSET ROWCOUNT IgnoreSELECT LastID = ID from testTable ORDER BY ID ASCENDELSEBEGINSET LastID = 0ENDSET ROWCOUNT PageSizeSELECT * FROM testTable WHERE ID LastID ORDER BY IDASC代码 2 SQL 存储过程支持自定义数据排序和分页此存储过程从逻辑上把 testTable 表的记录划分成 pageSize

10、页的记录,根据pageNumber 返回记录页数。记录由 ID 标识。这个存储过程的性能很大程度上取决于使用索引的字段标识和类型的索引:聚集或非聚集 4。通过使用索引的数据结构,我们可以显著地改善从数据库获得数据的所需时间。在我们的测试环境中,我们测试了几种不同的方案,有以下参数:(一)数据库中的记录数;(二)聚集和非聚集的数据库索引的使用;(三)ASP.NET 的服务器控件的自动数据分页和排序对比 SQL 存储过程的分页和排序。三、测试方法对于我们的测试环境,我们使用了惠普笔记本 550,性能如下:处理器:Intel Core 2 Duo CPU T5470 1.60 GHz;内存:2.00

11、 GB;操作系统 : Windows 7 Professional 32bit; Internet Information Server (IIS) Version 7.5.7600.16385; Visual Studio 2010 Ultimate; SQL Server 2008 R2。对于测试环境,我们创建了一个有两个网页的网络应用程序,正如第二节所解释的那样,其中每一个网页都有一个数据绑定、分页和排序方法。第一页使用自动数据绑定(ADB ):GridView 控件被允许可以分页和排序,正如代码 1 中说明的,可以通过一个存储过程,从数据库中得到所有的记录来填充 GridView 控件

12、。第二页使用的是一个自定义的存储过程(见代码 2)来用查询结果填充 GridView 控件。存储过程请求在SQL Server 上的结果,将只返回在网页中显示记录。根据 HTTP 请求的字符串查询,排序字段和页号可以被显示在网页上。我们对服务器的 HTTP 请求过程所需要的时间感兴趣。我们用 ASP.NET 跟踪特征来确定数据绑定发生时的页面生命周期。在 page_prerender 事件之后,我们打开计时器,开始于 page_init 事件,结束于 page_savestatecomplete 事件。在测试页面的功能是保持在最低限度,以避免响应时间的其他因素的影响。网页负责记录在文本文件中的

13、响应时间,并对这些时间测量结果进行了分析。我们的测试数据库有一个表,有五个字段。表中的记录填充有随机值。表 1:测试表 TESTTABLE 的字段名字 类型ID Int, autoincrementTextField Varchar(50)IntField IntBoolField BitDateField DateTime四、主要结果我们在图 1 的结果中显示数据表有 1,000,000 条记录。对于这两个测试页面中的任意一个来说,结果的类型有三种,这取决于是排序哪个字段的结果。这个实验中表testTable 没有测试索引。对每一个网页相应的排序和分页的方法进行了 500 次测试。测得的响应

14、时间分为 10 个 bins。图 1 显示了 bins 的频率。图 1 自动数据绑定 vs 无索引的自定义分页图 1 中的黑色曲线显示的是 ASP.NET 网页执行数据的排序和分页时使用自动数据绑定执行的结果。这种方法的问题是,在 ASP.NET 可以排序所有这些记录之前,数据源控件需要从数据库获取 1,000,000 条结果,并确定这些记录是属于请求页面的。ID字段是自动增加的,在数据库中,这些记录的物理排序是按照这个字段的。因此,ASP.NET 通过 ID 字段进行数据集排列所需要的时间是快于其他两种的。按照 Text Field排序和按照 Int field 排序的响应时间是不同,因为排

15、序 integer 字段比 textual 字段更快。图 1 中的红色曲线代表的是在数据库服务器上的排序和分页采用了代码 2 中所说的SQL 存储过程的结果。与 ADB 相比,响应时间显著缩短。原因是双重的:(一) SQL Server 为大型数据集工作而优化;(二)SQL 存储过程只要返回一小部分的记录就足以填充 ASP.NET 网页。排序不同列时的响应时间的差异是由解释 ADB 的同一原因造成的。接下来,在 testTable 表中有索引时,我们重复以上测试。目的是看使用聚集和非聚集索引时响应时间的不同。读者应该注意的是,图 2 使用了不同于图 1 的时间级别。图 2 自定义分页 IntF

16、ield 的聚集索引在图 2 中 testTable 表按照 Int Field 聚集,字段 ID 和 Text Field 是非聚集索引。由于聚集索引的原因,相对于按照 ID 和 Text Field 排序,按照 Int Field 排序的响应时间要少得多。这种聚集索引在不同的字段即 ID 或 Text Field 的模式重演:聚集索引排序的响应时间比非聚集索引的短。索引的存在不影响通过 SQL 服务器使用代码 1 的存储过程来完成 ASP.NET 网页上的排序和分页的响应时间。这和图一中黑色曲线所显示的结果是相同的。图 1 和图 2 中的一个特殊性质是两峰的存在。他们展现了在排序是用非索引

17、字段(图 1 中的所有曲线) ,或是一个非聚集索引的字段(图 2 中的 ID 和 Text Field) 。这意味着对于代码 2 中的 SQL 存储过程有两组时间响应。问题在于代码 2 的第二个选择语句“SELECT * FROM testTable WHERE ID LastID ORDER BY ID ASC”。我们发现输入参数pageNumber LastID ORDERBY int ASCSELECT testTable.* FROM #tLEFT JOIN testTable ON #t.x = testTable.int代码 3 对代码 2 中存储过程的修改代码 2 中的“SELE

18、CT *”语句可以分解成两个部分:第一部分通过索引字段请求记录,只把索引字段存储到临时表#t 中,同时只有 PageSize 条记录被存储。testTable 表中的索引和记录之间没有做连接,从而执行时间相对于第一部分是很短的。第二部分连接在临时表# t 的记录和在原始的 testTable 表的记录。自从做了PageSize 条记录的(例如 10 条记录)连接之后,第二部分也完成得很快。图 5 显示了使用了码 3 的修改过的 SQL 存储过程之后,数量级的提升。用非聚集索引对字段进行排序和分页,也实现了类似的改进。图 5 平均响应时间ms vs 聚集索引排序的页数pagenumber(二)可

19、扩展性 微软测试经理 5测试数据绑定机制的可扩展性。该测试工具可以从 IIS 模拟虚拟用户同时请求网页。它允许跟踪系统和应用程序的性能,通过监控不同的计数器,如可用内存,处理器的使用,平均页面响应时间等。我们进行了负载测试,以确定我们的应用程序在用户负载增加的情况下是怎么样的。我们在测试中,刚开始用少量的虚拟用户,然后慢慢地增加到 140 个虚拟用户。当用户超过 140 个时,我们的测试服务器用完了虚拟用户的数量,我们就测量平均页面响应时间。每一个负载测试运行 12 分钟,在最初的10 分钟被用于增加虚拟用户的数量,并在 2 分钟被用作冷却时间。在冷却期间,系统完成了启动请求,不再有新的请求被

20、处理 6。我们开始有 5 个用户,每分钟我们增加了 15个用户,直到我们达到 10 分钟的总时间和 140 个虚拟用户。从图 6 中可以看出,修改后的存储过程比原存储过程的响应时间更短。在任何领域,这都是有效的排序,从而提高了应用程序的可扩展性。图 6 平均响应时间ms vs 使用原始存储过程和修改过的存储过程的虚拟用户数五、结论 用 ASP.NET 的数据绑定控件的默认选项可以快速实现排序和分页功能。如果ASP.NET 的数据源控件是用来从数据库中获取所有的数据,数据绑定控件是用来分页排序数据集,然后响应时间就会随着返回的数据集规模而迅速增加。一个在 SQL 服务器上实现分页和排序的 SQL

21、 存储过程被使用是应该满足高性能低消耗的要求。可以花少量的时间获取数据,然后只把要显示的记录发送给 ASP.NET。如果对索引进行排序和分页,则可进一步减少响应时间。聚集索引的使用可以达到最佳的效果。代码 3 中修改后的存储过程的分页和排序使得网页应用程序的可扩展性有了显著的提高。参考文献:1 A. Bogardi-Meszoly, G. Imre, H. Charaf, “Investigating factors influencing the response time in J2EE web applications”, WSEAS Transactions on Computers,

22、 Vol. 4(2), February 2005, ISSN 1109-2750, pp. 179-184 2 MSDN, “ASP.NET Data Access Overview”, http:/ ms178359(v=vs.90).aspx 3 M. Mac Donald, A. Freeman and M. Szpuszta, “Pro ASP.NET 4 in C# 2010”, ISBN-10: 9781430225294, APress, 2010. 4 R. Ramakrishnan, J. Gehrke, “Database Management System”, ISBN-10: 0071230572, 3rd Edition, Mc Graw-Hill Higher Education, 2003 5 MSDN, “Testing Application Performance and Stress”, http:/ 6 MSDN, “Load Test Run Setting Properties”, http:/

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。