U9性能分析.doc

U9性能分析一、 AQTime使用AQTime是AutomatedQA公司开发的一个Code Profiler工具，可以一目了然知道性能消耗在什么地方，针对消耗有重点优化，其次针对调用次数多的地方，减少调用次数。1. 启动AQTime选择File|New Project，然后在Setup页签从右键菜单中选Add Module。2. 添加模块或可执行文件注：1、跟踪UI性能，需要加载PortalUILib下的*WebPart.dll2、跟踪AppServer性能，需要加载PortalApplicationServerLibs下的*BE.dll、*BP.dll、*SV.dll3、跟踪JOB性能，需要加载PortalApplicationServerServiceHostingConsole.exe文件。3. 设置跟踪模式注：1、跟踪UI性能，选择ASP.NET2、跟踪AppServer和JOB，选择Normal4. 配置启动参数注：设置启动也为portal地址注：1、勾选“Profile Entire .NET Code by Routines”，则AQTime自动会把需要跟踪节点关联的BP、SV和平台等所有相关的代码性能都会收集到，如果没有勾选，则左边添加“Modules”时，需要把跟踪节点涉及到的BP、SV和平台dll都需要加载。2、在没进入跟踪节点时，需要先“Disable Profiling”，到了跟踪点再“Enable”，跟踪点结束后也需要“Disable”。5. 启动注：直接Run，不用修改“Thread model”和“Active counter”。6. 获取跟踪结果注：跟踪节点完成后，先“Disable Profiling”，然后“Get Results”获取结果。1、“Routine Name”节点所调用的BP、SV、方法名称2、“Time”本BP、SV、方法消耗时间（秒）3、“Time with Children” BP、SV、方法其调用链全部消耗时间（秒）4、“Hit Count” BP、SV、方法在本次跟踪总调用次数。7. 分析结果注：结果可以按树形展开（Call Tree），也可以按图形展开（Call Graph）8. AQTime性能分析案例销售订单性能问题问题1：前端PreRender消耗过大总消耗8.18秒，其中前端PreRender就要消耗1.9秒，基本就是Session.Commit消耗的一半：BeforeUIModelBinding和AfterUIModelBinding消耗最终着落在GetEffectiveChildRecords上：厉害，GetEffectiveChildRecords总计被调用了6578次！是被这些方法触发的：问题2：OnInserting事件消耗在Session.Commit共3.88秒消耗中，我们注意到OnInserting事件就消耗掉了1.19秒：原因是调用了98次GetSDItemCostBP ：该BP最大消耗在加载较为重型的ItemMaster对象上，其次为执行存储过程和调用另一BP。问题3：OnSetDefaultValue事件这个事件处理也有问题：其中一个主要消耗是发出了约300次Find查询。SMTools这种东东还在用？问题4：OnValidate事件消耗算法有些低效，但改进方案呢。问题5：ControlObj.Copy的消耗一次保存操作共触发CBO.Controller的事件798次：共计会触发294次Find操作，基础的公共方法，实现效率需要改进：小结销售订单功能点自身实现存在性能问题，估计有3秒左右的优化空间。如此，百行订单包括IE客户端消耗后时间可能达到67秒之间。二、 SQL Server Profiler使用SQL Server Profiler 是图形化实时监视工具，能帮助系统管理员监视数据库和服务器之行为, 比如死锁之数量，致命之错误，跟踪Transact-SQL 语句和存储过程。可以把这些监视数据存入表或文件中，并在以后某一时间重新显示这些事件来一步一步之进行分析。1. 启动SQL Profiler新建一个跟踪“文件|新建跟踪”2. 选择模版选择“Tuning”模版3. 事件选择4. 运行运行跟踪，执行portal需跟踪节点的动作。5. 另存跟踪结果把跟踪结果另存为表，以备后续查询使用。6. 分析跟踪结果查询跟踪结果中消耗时间比较长的SQL语句和存储过程，把语句或存储过程拷贝出来单独执行，执行时附上“执行计划”，看看是否需要建立索引等等。7. SQL Server Profiler分析案例背景说明大冶成本计算执行时间从4个小时暴增到10个小时。本文档从数据库角度对成本计算执行时间进行分析。思路成本计算时间主要消耗在费用取数上，而费用取数是以2000条记录作为一个执行批次，一共执行90次（分析环境）。由于每次重复执行相同的动作，SQL执行次数*单独运行时间=SQL总消耗。 使用跟踪工具在数据库端收集了运行30次的SQL语句。分析SQL分组统计按照SQL前835个字符进行分组，如果前835个字符相同的SQL认为是同类SQL。统计这些同类SQL的总消耗，确定时间消耗的重点动作。select SUBSTRING(cast(textdata as nvarchar(max),1,835) as sql835,COUNT(*) as executeCounts ,SUM(duration)/1000/1000 as sumduration_second,SUM(cpu) as sumcpu,SUM(reads) as sumreads,SUM(writes) as sumwritesfrom dbo.cbjs_27group by SUBSTRING(cast(textdata as nvarchar(max),1,835)order by SUM(duration)/1000/1000 descInvTrans_TransLineSourceselect A.*, A1.SrcDocTypeName, A2.Code as SysMlFlag from InvTrans_TransLineSource as A left join Base_Language as A2 on (A2.Effective_IsEffective = 1) left join InvTrans_TransLineSource_Trl as A1 on (A1.SysMlFlag = A2.Code) and (A.ID = A1.ID) where (A.TransLine = TransLine) order by A.DocSubLine_EntityID asc, A.TransLine asc, A.Trans asc, A.RelateTransLine asc, A.LogisticOrg asc执行61535次，总耗时2553秒。平均每次执行需要41毫秒。因为收集的是30次计算，整个取数过程（90次），需要时间2553*3=2.12小时。执行计划：过滤条件和排序条件都是包含在业务主键中。但是执行计划显示并没有使用这个索引。索引字段顺序不正确！说明：sp1中发现索引设计器没有存储索引顺序的后遗症主键显现出来了。现场只要使用升级工具打补丁，都可能将索引字段顺序搞乱。大冶现场还是使用有问题的升级工具。这个问题在sp1中无法彻底解决，sp2才能解决。正确的顺序：调整后的执行计划：MOCost_P_ReWriteIssueCostexec MOCost_P_ReWriteIssueCost Org=N1000808070100035,ExchRateType=N0存储过程执行30次，耗时313秒。总时间需要919秒。需要建立两个索引：/* Object: Index IX_MOPick Script Date: 05/13/2009 11:22:59 */IF EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(Ndbo.MO_IssueDocLine) AND name = NIX_MOPick)DROP INDEX IX_MOPick ON dbo.MO_IssueDocLine WITH ( ONLINE = OFF )GOcreate index IX_MOPickon MO_IssueDocLine(MOPick)GO/* Object: Index IX_PLS Script Date: 05/13/2009 11:23:21 */IF EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(Ndbo.MO_IssueDocLine) AND name = NIX_PLS)DROP INDEX IX_PLS ON dbo.MO_IssueDocLine WITH ( ONLINE = OFF )GOcreate index IX_PLSon MO_IssueDocLine(PLS)GO批次记录查询exec sp_executesql NSELECT * FROM ( SELECT A.*, A1.ManufacturerInfo_Name, A1.DescFlexField_CombineName, A1.SrcDocTypeName, A1.ODDocTypeName, A1.CostSrcDocTypeName, A1.CustomerInfo_Name, A1.SupplierInfo_Name, A1.DocTypeName, A2.Code as SysMlFlag , ROW_NUMBER() OVER(ORDER BY A.ID ) AS rownum FROM InvTrans_TransLine as A left join Base_Language as A2 on (A2.Effective_IsEffective = 1) left join InvTrans_TransLine_Trl as A1 on (A1.SysMlFlag = A2.Code) and (A.ID = A1.ID) left join CBO_ItemMaster as A3 on (A.ItemInfo_ItemID = A3.ID) left join CBO_MfgInfo as A4 on (A3.MfgInfo = A4.ID) WHERE (1 = 1) and (A.Org = org) and (A.Direction = Direction) and (A.OutStockCostSrc = OutStockCostSrc) or (A.OutStockCostSrc = OutStockCostSrc2) or (A.Direction = Direction2) and (A.DocBizType = DocBizType) and (A.CostSrcDoc_EntityID PageLowerBound and T.rownum= PageUpperBound,Norg bigint,Direction int,OutStockCostSrc int,OutStockCostSrc2 int,Direction2 int,DocBizType int,AccountPeriod bigint,LowLevelCode int,PageLowerBound bigint,PageUpperBound bigint,org=1000808070100035,Direction=1,OutStockCostSrc=7,OutStockCostSrc2=0,Direction2=0,DocBizType=448,AccountPeriod=1000810235124403,LowLevelCode=5,PageLowerBound=60000,PageUpperBound=62000运行31次耗时210秒。总时间消耗：609秒。需要建立三个索引：-CBO_ItemMaster/* Object: Index IX_MfgInfo Script Date: 05/13/2009 12:44:58 */IF EXISTS (SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID(Ndbo.CBO_ItemMaster) AND name = NIX_MfgInfo)DROP INDEX IX_MfgInfo ON dbo.CBO_ItemMaster WITH ( ONLINE = OFF )GOcreate index IX_MfgInfoon CBO_ItemMaster(ID)include(MfgInfo,IsPurchaseEnable)GO-CBO_MfgInfo/* Object: Index IX_LowLevelCode Script Date: 05/13/2009 12:45:44 */IF EXISTS (SELECT * FROM sys.indexes WHERE object_id =