Analyzing Specific Performance Problems

本文介绍了一种用于技术分析和应用分析的工作负载监控工具,通过该工具可以检查个别交易的性能。主要内容包括如何通过交易配置文件来评估活动水平和系统负载,并提供了响应时间的指导值。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

The workload monitor is an analysis tool used for both technical analysis and application analysis, with which you can check the performance of individual transactions.


Is There a Performance Problem with a Transaction?

Transaction profile

The transaction profile is of primary importance for application analysis Transaction profile. To change over to the transaction profile, select TRANSACTION
PROFILE UNDER ANALYSIS VIEWS in the lower-left window of the workload monitor. The transaction profile contains a list of all transactions (or programs) started in the selected period. The number of transaction steps for each transaction is recorded (NUMBER OF STEPS) and is a measure of the activity of a transaction. Other columns in the transaction profile show the total and average response times and the proportions of CPU time, dispatcher wait time, and database time. Using the tabs in the menu
interface, you can select other screens with information about database accesses and so on.



Activity

From the number of transaction steps (NUMBER OF STEPS), you can estimate how frequently the transaction was executed if you know how many transaction steps (screen changes) each regular user requires on average per procedure. For example, if a regular user requires an average of five transaction steps to create a sales order (Transaction VA01), and the transaction profile shows 100,000 transaction steps for the selected time period,you can calculate that 20,000 sales orders were created.
To see which transaction had the most activity, sort by the NUMBER OF STEPS column.


Load

The TOTAL RESPONSE TIME column displays a measure for the entire load on the system.  To find out which transactions produced the most load on the system, sort the list by the columns TOTAL RESPONSE TIME, TOTAL CPU TIME, and/or TOTAL DB TIME. After each sort, the programs at the top of the list are likely candidates for performance optimization.


Average response time

For users. the average response time of transactions is an important index of performance. Monitor and create guideline values for the average response times of core transactions - that is, transactions in which performance is central to business operations. In general, when analyzing the transaction profile, consider the following questions:

->Sort the transaction profile according to TOTAL DB TIME. Which transactions cause the greatest database load?

->Sort the transaction profile according to TOTAL CPU TIME. Which transactions cause the greatest CPU load?

->Are there transactions for which the proportion of database time or CPU time is significantly higher than 60% of the total response time? Analyze these transactions using an SQL trace or ABAP trace. 

->Are there any customer-developed programs or transactions that produce a large load?

Monitor and save a copy of the transaction profile at regular intervals. This enables you to determine whether the response times of individual transactions grow continuously over time or whether there is a sudden worsening of response times after a program modification. By recognizing these trends early in the transaction profile, you can initiate a detailed program analysis before a program causes bottlenecks for the entire process chain -or worse, reduces the performance of the entire SAP system due to heavy CPU or database loads.


Guideline values for response times

provides explanations and guideline response times for common Guideline values system transactions. These programs can usually be ignored during the for response times performance analysis

System Programs in the Transaction Profile (Cont.)

Transaction/ProgramDescription/CommentGuideline Response Time
MainMenuActions in the menu. MainMenu 
frequently appears near the top of the
list if sorted according to Transaction
Steps.
< 100 ms
Login_Pw/LogoffLogon or logoff screen. 
AutoABAPThe AutoABAP runs periodically in the 
background and executes actions like
those required by the Alert Monitor.
< 1,000 ms
Buf . SyncBuffer synchronization.< 1,000 ms
Rep_EditActions in the ABAP Editor. 
(B)SCHDLThe batch scheduler runs periodicallly
and checks whether background
programs are due to be started.
 
RSCOLL00The performance collector runs
periodically and collects data on
performance. This program is
frequently near the top of the list
of expensive programs for the total
response time. However, the CPU
TIME TOTAL and DB TIME TOTAL
columns indicate that this program
requires very little CPU or database
time. Most of the response time for
this program occurs when it is waiting
in work processes for performance
data.
 
RSM13000The update program is used to
summarize all update module
statistics that cannot be ascribed to a
transaction.
 < 3.000 ms

















内容概要:文章基于4A架构(业务架构、应用架构、数据架构、技术架构),对SAP的成本中心和利润中心进行了详细对比分析。业务架构上,成本中心是成本控制的责任单元,负责成本归集与控制,而利润中心是利润创造的独立实体,负责收入、成本和利润的核算。应用架构方面,两者都依托于SAP的CO模块,但功能有所区分,如成本中心侧重于成本要素归集和预算管理,利润中心则关注内部交易核算和获利能力分析。数据架构中,成本中心与利润中心存在多对一的关系,交易数据通过成本归集、分摊和利润计算流程联动。技术架构依赖SAP S/4HANA的内存计算和ABAP技术,支持实时核算与跨系统集成。总结来看,成本中心和利润中心在4A架构下相互关联,共同为企业提供精细化管理和决策支持。 适合人群:从事企业财务管理、成本控制或利润核算的专业人员,以及对SAP系统有一定了解的企业信息化管理人员。 使用场景及目标:①帮助企业理解成本中心和利润中心在4A架构下的运作机制;②指导企业在实施SAP系统时合理配置成本中心和利润中心,优化业务流程;③提升企业对成本和利润的精细化管理水平,支持业务决策。 其他说明:文章不仅阐述了理论概念,还提供了具体的应用场景和技术实现方式,有助于读者全面理解并应用于实际工作中。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值