.Net+SQL Server企业应用性能优化笔记4——精确查找瓶颈

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
简介:

前面几篇优化笔记写的太过概括,有朋友建议我把优化的步骤和方法写详细点,这篇比较我就详细讲解下使用ANTS Profiler+SQL Server Profiler查找瓶颈所在。

首先我们需要部署一个测试环境,将Web项目的源代码拷到测试环境Web服务器IIS上,使得可以直接通过IE访问我们的网站。SQL Server环境可以部署在同一台机器上,条件允许的话有专门的数据库测试服务器那当然是更好,没有也无所谓。部署完测试环境后保证我们这个测试环境没有其他用户在访问,只有我们访问,免得其他用户的操作影响了我们。

假设我们的网站在首页打开的时候很慢,需要10多秒钟才能打开,首页打开是调用了多个函数,函数中调用了多个存储过程,到底是哪个函数慢?到底是哪个存储过程慢?是Web服务器上的函数执行花费了大量的时间还是数据库中的存储过程执行花费了大部分时间?到底每个函数,每个存储过程各自花费了多少时间呢?这些问题就需要通过ANTS Profiler和SQL Server Profiler来解决。

使用ANTS Profiler和SQL Server Profiler进行瓶颈查找的过程如下:

(1)在Web服务器上安装并打开ANTS Profiler,在Profiler项目向导中选择Profiler类型为详细模式,如图所示:

image

(2)单击“下一步”按钮,出现要进行跟踪的应用程序类型,这里是将项目发布到IIS中的,所以选择第二个。

image

(3)单击“下一步”按钮,出现ASP.NET应用程序配置界面,设置应用程序起始页、.NET版本、IIS版本和要进行跟踪的端口。

image

(4)单击“下一步”按钮进入代码跟踪选择界面,选择将所有的.NET方法进行跟踪,也可以选择第一个选择,只对有调试文件和源代码的方法进行跟踪。

image

(5)这里我们要跟踪的是首页,所以一旦单击“完成”按钮系统就会打开IE浏览器载入首页,在单击“完成”按钮之前,需要对测试环境数据库开启SQL Server Profiler。SQL Server Profiler负责跟踪数据库上执行的脚本情况,建议将跟踪结果保存到数据库中,这样可以通过SQL语句来查找跟踪的脚本。将跟踪结果保存到数据库的配置如下图:

image

(6)对于跟踪事件,如果是进行简单的性能跟踪,则只需要选中RPC:Completed和SQL:BatchCompleted两个事件即可。至于关注的列,主要是关注TextData、CPU、Reads、Writes、Duration等列,其他列不用特别关心,采用默认选项即可,如图所示:

image

(7)单击SQL Server Profiler中的“运行”按钮,开始对数据库的跟踪,然后单击ANTS Profiler向导中的“完成”按钮,开启对ASP.NET应用程序的跟踪。

(8)系统将打开IE浏览器,提示输入有效的用户名和密码,过几十秒钟后,首页就可以完整展示出来了。SQL Server Profiler中也跟踪到了大量在首页载入时执行的SQL语句和存储过程。

(9)单击ANTS Profiler工具栏中的“获得快照”按钮,系统将会为ASP.NET应用程序建立快照,然后列出从运行开始到快照时刻系统中执行时间最长的方法和方法的源代码,如图所示:

image

(10)从上图中可以看到当前最长时间的一个方法是ViewMainQueryFGS.aspx.cs中的Page_Load方法,该方法花费了13.27秒,而具体花费时间的地方是在Page_Load方法中调用了BindTable方法。

(11)使用VS打开程序源代码,或者是在ANTS Profiler中,点击查看BindTable方法,我们可以看到该方法中有两个函数调用比较耗时,一个是378行,花费了11.1秒,另一个是38行,花费了2.14秒,如图所示。

image

(12)使用同样的方法可以查看到GetDataListBySQL方法具体调用了哪些方法,各个方法多少秒。这里通过查看源代码我们可以知道,该方法最终是调用了数据层中的p_cx_prodplanfinish存储过程,切换到SQL Server Profiler,我们可以看到系统调用该存储过程花费了10.98秒。

image

(13)现在我们再回过头来算一下,整个页面载入花了13.27秒(Page_Load方法的时间),其中光执行这个存储过程就花了10.98秒,显然,这个瓶颈是在存储过程p_cx_prodplanfinish上,首先应该对该存储过程进行优化。另外还有个2.14秒的地方调用了另外一个存储过程,也可以进行优化。

使用同样的方法,用ANTS Profiler和SQL Server Profiler就可以找出具体是哪个函数最耗时,耗了多少时间,哪个存储过程最耗时,耗了多少时间。确定了到底是应用程序消耗了大量时间还是存储过程消耗了大量时间,接下来可以有的放矢了。

这篇文章是我半个月前完成的,但是由于接下来出差,所以一直没有发表,现在出差完了,终于有时间发表该文章了。

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
3天前
|
SQL 存储 监控
SQL Server的并行实施如何优化?
【7月更文挑战第23天】SQL Server的并行实施如何优化?
23 13
|
1天前
|
SQL 缓存 监控
14个Flink SQL性能优化实践分享
【7月更文挑战第12天】 1. **合理设置并行度**: 根据数据量和资源调整以提高处理速度. 2. **优化数据源**: 使用分区表并进行预处理减少输入量. 3. **数据缓存**: 采用 `BROADCAST` 或 `REPARTITION` 缓存常用数据. 4. **索引和分区**: 创建索引并按常用字段分区. 5. **避免不必要的计算**: 检查并移除多余的计算步骤. 6. **调整内存配置**: 分配足够内存避免性能下降. 7. **优化连接操作**: 选择适合大表和小表的连接方式. 8. **数据类型优化**: 选择合适类型以节省资源. ........
|
5天前
|
SQL 存储 数据库
性能分析工具如Sql explain、show profile和mysqlsla在数据库性能优化中有什么作用
性能分析工具如Sql explain、show profile和mysqlsla在数据库性能优化中有什么作用
|
7天前
|
存储 SQL C++
对比 SQL Server中的VARCHAR(max) 与VARCHAR(n) 数据类型
【7月更文挑战7天】SQL Server 中的 VARCHAR(max) vs VARCHAR(n): - VARCHAR(n) 存储最多 n 个字符(1-8000),适合短文本。 - VARCHAR(max) 可存储约 21 亿个字符,适合大量文本。 - VARCHAR(n) 在处理小数据时性能更好,空间固定。 - VARCHAR(max) 对于大文本更合适,但可能影响性能。 - 选择取决于数据长度预期和业务需求。
|
11天前
|
SQL Oracle 关系型数据库
MySQL、SQL Server和Oracle数据库安装部署教程
数据库的安装部署教程因不同的数据库管理系统(DBMS)而异,以下将以MySQL、SQL Server和Oracle为例,分别概述其安装部署的基本步骤。请注意,由于软件版本和操作系统的不同,具体步骤可能会有所变化。
42 3
|
16天前
|
SQL 存储 安全
数据库数据恢复—SQL Server数据库出现逻辑错误的数据恢复案例
SQL Server数据库数据恢复环境: 某品牌服务器存储中有两组raid5磁盘阵列。操作系统层面跑着SQL Server数据库,SQL Server数据库存放在D盘分区中。 SQL Server数据库故障: 存放SQL Server数据库的D盘分区容量不足,管理员在E盘中生成了一个.ndf的文件并且将数据库路径指向E盘继续使用。数据库继续运行一段时间后出现故障并报错,连接失效,SqlServer数据库无法附加查询。管理员多次尝试恢复数据库数据但是没有成功。
|
22天前
|
SQL 存储 关系型数据库
关系型数据库SQL Server学习
【7月更文挑战第4天】
26 2
|
27天前
|
SQL 存储 测试技术
|
26天前
|
SQL 机器学习/深度学习 搜索推荐
SQL SERVER 转换失败
【6月更文挑战第25天】
|
5天前
|
SQL 监控 数据库
SQL Server 查询超时问题排查
【7月更文挑战第8天】排查 SQL Server 查询超时涉及五个主要方面:检查复杂查询、评估服务器性能、审视配置参数、更新统计信息和分析执行计划。关注点包括查询的结构(如连接、子查询和索引),服务器资源(CPU、内存、网络延迟),连接和内存设置,以及统计信息的时效性。通过这些步骤可定位并解决性能瓶颈。