Average Response Times for a Reports Server

On Application Server Control and Grid Control are sections listing the Average Response Time in milliseconds.
Can anyone tell me what response it is measuring exactly?
Thanks
Andy

See the Online Help for the page for a description of the metric. In Help, you can search for "metric" to see definitions of the other metrics.

Similar Messages

ISA Server 2006 + Average response time for Non Cached requests = performance issues?!?!?!

All,
I am in a predicament with internet browsing speeds...We have a 3rd party look after our line and internet facing f/w so I cant troubleshoot them, so at the moment Im looking at ISA as the potential bottleneck - we have a fairly standard environment:
Internal > Local Host > Perimiter n/work > Firewall > Internet
I have been running custom reports on the ISA server to see what data can be collected - I have noticed that "Average response time for non cached requests" (traffic by time of day) can be as high as 76 seconds!!!!!! Cached hits are between .5
and 2 seconds.
I have also coonfigured a connectivity verifier which is also flagging slow connectivity, massively over the >5000ms and also reporting "cant resolve server name on occassions- and this is configured for
www.Microsoft.com --- DNS ???!?!, however I have looked through DNS (no obvious errors / config issues) which I can see
I have run the BPA on ISA server to ensure its Health - - connectivity verifier errors flagged timeouts to microsoft.com as expected...
Can anyone advise any obvious areas to investigate as Im struggling! - as always the 3rd party have told us the internet pipe is fine :O

Problem resolved.
DNS forwarders have been changed on the ISA server / DNS and this has improved lookup speed considerably.
thanks all :)

Average Response Time for Reports

Hi Gurus,
I am using OAS 10.1.2.0.2 with Business Intelligence and Forms Installation.
Previously I have never seen Average Response Time of Reports server greater than 10000(ms),
But It is increasing continously and now within 2-3 days it has increased upto 114668(ms)
CPU Usage (%)          N/A
     Memory Usage (MB)          N/A
     Average Response Time (ms)          114668
its Maximum queue size is 1000....
I am not able to find out why it is increasing in this manner.....
plz help..
Thanx

Hi,
Today it has been increased upto 170236 ...
Thanx,
Santosh

Average response times for VA01 and VA02 transactions

Hi,
we have some users complaining about response times, more specific for VA01 and VA02 transactions. We would like to compare our average response times to those of other companies in order to get an idea of what is acceptable to most companies. If you are willing to contribute, can you please send a few hours of STAD data (only for VA01 and VA02 transactions) of an average working day? Perhaps you can download the data into a spreadsheet and mail the zipped file to my account Many thanks.
Best regards,
Guido Van Leuven

Hi,
This is not the issue. We are investigating everything possible to improve our response times and we believe that that these are ok as well. We just want to build a case where we can prove that our response times are not worse than those at other companies and that we can do only by comparing those statistics.
Best regards,
Guido Van Leuven

Urgent:How to Speed Up the Response time for PDF Report of 500 pages

hi all
i am running the 9ias on Solaris and Generating some reports
Which fetches around 50,000 records and Display them in pdf format.
When i am ruuning the Query at Database level Response time is Very fast.
But when i Run the Report in Web Browser same report takes 7-8 minutes.
So it seems that the Conversion to pdf and Displaying it takes most of time.
Does any one has idea What parameter's needs to be changed/Caching ??? /
or any other ways or methods which can be used to Reduce the Response time.
(its once a monthly Report and User need to Download all the 500 pages as
a Single Document).
Any help / suggestion please
thanks
jai

You aren't by any chance calling a function in your repeating frame that in turn goes back and queries the database, are you? If so ... don't. We regularly do 500+ page PDF-file reports, and one thing we discovered early on was that repeatedly going back to the database while generating the report output (in our case, in calculations that were being done on each line of a report) slowed the output down by an order of magnitude. Instead, we now retrieve all the data needed for each report up front (via functions or views called in the initial SQL for the report), and just use Reports to format the output. MUUUUUUUCH faster -- 200 page reports that used to take 15 minutes to complete now complete in just seconds.
One way you can visually see if this is part of your problem is to watch the report execute in the Report Queue Manager application. If it spends all its time on the "Opening" stage then breezes through each page, this is not your problem. If instead it seems to take a long time generating each page, I'd suspect that this may be at least part of your delay.
- Bill

ACE 4710: Find out the response time of a real server

Hi to everyone,
I have a couple of ACE 4710 and I need to find out what is the response time of a real server.
Is there a way for this?
Thank you for any answer!
giorgio romano

Hi,
Kindly add the following line in your serverfarm configuration:
predictor response syn-to-synack
Suppose your serverfarm looks like this:
serverfarm host AAA_FARM
predictor response syn-to-synack
probe HTTP_PROBE
probe TCP9001_PROBE
rserver SC106
inservice
rserver SC107
inservice
rserver SC108
inservice
rserver SC109
inservice
rserver SC110
inservice
rserver SC111
inservice
rserver SC112
inservice
rserver SC113
inservice
rserver SC114
inservice
rserver SC120
inservice
rserver SC131
inservice
And then use the following command to see the average response time from your rserver as follows:
ACE1/prod# show serverfarm AAA_FARM detail
serverfarm     : AAA_FARM, type: HOST
total rservers : 11
active rservers: 11
description    : ServerFarm AAA
state          : ACTIVE
predictor      : RESPONSE
method            : syn-to-synack
samples           : 8
failaction     : -
back-inservice    : 0
partial-threshold : 0
num times failover       : 0
num times back inservice : 0
total conn-dropcount : 0
Probe(s) :
HTTP_PROBE, type = HTTP
TCP9001_PROBE, type = TCP
----------connections-----------
real                  weight state        current    total      failures
---+---------------------+------+------------+----------+----------+---------
rserver: SC106
x.x.x.x.:0        8      OPERATIONAL 2          1125       0
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
average response time (usecs) : 81   ----> thats what you might be looking for
From other day :
rserver: SC114
x.x.x.x:0        8      OPERATIONAL 70         10903      2
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
         average response time (usecs) : 1334                       ----> thats what you might be looking for
For Serverfarm BBB_FARM
serverfarm     : BBB_FARM, type: HOST
total rservers : 1
active rservers: 1
description    : ServerFarm BBB
state          : ACTIVE
predictor      : RESPONSE
method            : syn-to-synack
samples           : 8
failaction     : -
back-inservice    : 0
partial-threshold : 0
num times failover       : 1
num times back inservice : 1
total conn-dropcount : 0
Probe(s) :
----------connections-----------
real                  weight state        current    total      failures
---+---------------------+------+------------+----------+----------+---------
rserver: SC208
x.x.x.x:0        8      OPERATIONAL 0          0          0
max-conns            : 4000000   , out-of-rotation count : 0
min-conns            : 4000000
conn-rate-limit      : -         , out-of-rotation count : -
bandwidth-rate-limit : -         , out-of-rotation count : -
retcode out-of-rotation count : -
load value           : 0
         average response time (usecs) : 0   ----> thats what you might be looking for
Use more detials for response predictor:
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA3_1_0/configuration/slb/guide/rsfarms.html#wp1068831
Configuring the Application Response Predictor
To instruct the ACE to select the server with the lowest average response time for the specified response-time measurement based on the current connection count and server weight (if configured), use the predictor response command in server farm host or redirect configuration mode. This predictor is considered adaptive because the ACE continuously provides feedback to the load-balancing algorithm based on the behavior of the real server.
To select the appropriate server, the ACE measures the absolute response time for each server in the server farm and averages the result over a specified number of samples (if configured). With the default weight connection option configured, the ACE also takes into account the server's average response time and current connection count. This calculation results in a connection distribution that is proportional to the average response time of the server.
The syntax of this command is as follows:
predictor response {app-req-to-resp | syn-to-close | syn-to-synack}[samples number]
The keywords and arguments are as follows:
•app-request-to-resp—Measures the response time from when the ACE sends an HTTP request to a server to the time that the ACE receives a response from the server for that request.
•syn-to-close—Measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives a CLOSE from the server.
•syn-to-synack—Measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives the SYN-ACK from the server.
•samples number—(Optional) Specifies the number of samples over which you want to average the results of the response time measurement. Enter an integer from 1 to 16 in powers of 2. Valid values are 1, 2, 4, 8, and 16. The default is 8.
For example, to configure the response predictor to load balance a request based on the response time from when the ACE sends an HTTP request to a server to when the ACE receives a response back from the server and average the results over four samples, enter:
host1/Admin(config)# serverfarm SFARM1
host1/Admin(config-sfarm-host)# predictor response app-req-to-resp
samples 4
To reset the predictor method to the default of round-robin, enter:
host1/Admin(config-sfarm-host)# no predictor
To configure an additional parameter to take into account the current connection count of the servers in a server farm, use the weight connection command in server farm host predictor configuration mode. By default, this command is enabled. The syntax of this command is as follows:
weight connection
For example, enter:
host1/Admin(config)# serverfarm SF1
host1/Admin(config-sfarm-host)# predictor response app-request-to-resp
samples 4
host1/Admin(config-sfarm-host-predictor)# weight connection
To remove the current connection count from the calculation of the average server response time, enter:
host1/Admin(config-sfarm-host-predictor)# no weight connection
You can use threshold milliseconds parameter which is optional Specifies the required minimum average response time for a server. If the server response time is greater than the specified threshold value, the ACE removes the server from the load-balancing decision process (takes the server out of service).
Enter an integer from 1 to 300000 milliseconds (5 minutes). The default is no threshold (servers are not taken out of service).
In case if you have measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives a CLOSE from the server use syn-to-close      (already discussed previously)
If you have to measures the response time from when the ACE sends a TCP SYN to a server to the time that the ACE receives the SYN-ACK from the server use syn-to-synack   (already discussed previously)
SAMPLES parameter is optional and specifies the number of samples that you want to average from the results of the response time measurement and response time is used to select the server with the lowest response time for the requested response-time measurement. If you do not specify a response-time measurement method, the ACE uses the HTTP app-req-to-response method.
Whenever a server's load reaches zero, by default, the ACE uses the autoadjust feature to assign a maximum load value of 16000 to that server to prevent it from being flooded with new incoming connections. The ACE periodically adjusts this load value based on feedback from the server's SNMP probe and other configured options.
Using the least-loaded predictor with the configured server weight and the current connection count option enabled, the ACE calculates the final load of a real server as follows:
final load = weighted load Ã— static weight Ã— current connection count
where:
â€¢weighted load is the load reported by the SNMP probe
â€¢static weight is the configured weight of the real server
â€¢current connection count is the total number of active connections to the real server
The ACE recalculates the final load whenever the connection count changes, provided that the (config-sfarm-host-predictor) weight connection command is configured. If the (config-sfarm-host-predictor) weight connection command is not configured, the ACE updates the final load when the next load update arrives from the SNMP probe.
If two servers have the same lowest load (either zero or nonzero), the ACE load balances the connections between the two servers in a round-robin manner.
HTH
Plz rate if u find it useful.
Sachin

ASM & Average Response Time

Greetings All, I was hoping that others may have some insight into DB Control and how is reports ASM Disk response times.
First my environment:
Oracle RAC 11g R1 Standard Edition, Patchset 12
Two Node Cluster
Windows x64 2003 R2 DataCenter Edition.
I am leveraging DB Control to monitor the ASM instances along with the db instances. My issue is regarding how db control gathers metrics to report on average response time for the DISKS that make up the Disk Group.
I have two issues:
1.) The overall response time reported in db control for my disk group "DATA" does not jive with the average I calculate based on the numbers being reported by db control. E.g.) I have ten LUNS in my DATA disk group and if I calculate the mean avg response time from each individual disk as reported by db control I don't get the same number being reported by db control. The numbers differ by as much as 20%.
2.) The numbers reported by ASM for avg response time for each LUN in the disk group are not the same from disk to disk. E.g.) In my current production environment here are the Avg Response Times for each LUN in the group:
8.73, 11.38, 5.22, 4.13, 3.04, 15.84, 12.71, 12.91, 10.51, 9.25.
I would have expected that these disks would have had the same avg response time because ASM is working to guarantee that each disk has the same number of I/O's.
The disk array has identical disks for all 10.
Further, the average for all disks as being reported by db control is : 7.28.
If I do the math I get an average of 9.38, the % diff between these two numbers is 28%
I have heard that db control does a poor job of reporting on ASM disk metrics but this is just people grumbling. I was hoping that someone out there may have some solid facts regarding db control and ASM.

hey....
maybe its be better off to open a generel discussion task on metalink....
*T

Report to calculate avg response time for a transaction using ST03.

Hi Abap Gurus ,
I want to develop a report which calculates the average response time(ST 03) for a transaction on hourly basis.
I have read many threads like in which users are posting which tables/FM to use to extract data such as dialog step and total response time .
I am sure many would have created a report like this , would appeciate if you can share pseudo code for same.Any help regarding the same is highly appreciated...
Cheers,
Karan

http://jakarta.apache.org/jmeter/

Significant difference in response times for same query running on Windows client vs database server

I have a query which is taking a long time to return the results using the Oracle client.
When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
When I run the same query on a Windows client it completes in 47 minutes.
Ideally I would like to get a response time equivalent on the Windows client to what I get when running this on the database server.
In both cases the query plans are the same.
The query and plan is shown below :
{code}
SQL> explain plan
2 set statement_id = 'SLOW'
3 for
4 SELECT DISTINCT /*+ FIRST_ROWS(503) */ objecttype.id_object
5 FROM documents objecttype WHERE objecttype.id_type_definition = 'duotA9'
6 ;
Explained.
SQL> select * from table(dbms_xplan.display('PLAN_TABLE','SLOW','TYPICAL'));
PLAN_TABLE_OUTPUT
| Id | Operation          | Name      | Rows | Bytes |TempSpc| Cost (%CPU)|
|   0 | SELECT STATEMENT   |           | 2852K|    46M|       | 69851   (1)|
|   1 | HASH UNIQUE       |           | 2852K|    46M|   153M| 69851   (1)|
|* 2 |   TABLE ACCESS FULL| DOCUMENTS | 2852K|    46M|       | 54063   (1)|
{code}
Are there are configuration changes that can be done on the Oracle client or database to improve the response times for the query when it is running from the client?
The version on the database server is 10.2.0.1.0
The version of the oracle client is also 10.2.0.1.0
I am happy to provide any further information if required.
Thank you in advance.

I have a query which is taking a long time to return the results using the Oracle client.
When I run this query on our database server (Unix/Solaris) it completes in 80 seconds.
When I run the same query on a Windows client it completes in 47 minutes.
There are NO queries that 'run' on a client. Queries ALWAYS run within the database server.
A client can choose when to FETCH query results. In sql developer (or toad) I can choose to get 10 rows at a time. Until I choose to get the next set of 10 rows NO rows will be returned from the server to the client; That query might NEVER complete.
You may get the same results depending on the client you are using. Post your question in a forum for whatever client you are using.

Can Cisco Historical Reports Report Average Hold Time for Incoming Calls?

Is the a way that Cisco Historical can report on the Average Hold Time for Incoming Calls? User is trying to figure out if there is a hold time prior to the agent picking up the call.
I am running CRS Historical Reports Versions 5.0 (2.5).

Hi,
You can check the link belowCisco Unified Contact Center Express 5.0 Historical Reporting Administrator and Developer Guide:
http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_5_0/programming/hr_admin_devp/crs501hd.pdf
this document includes all the details regarding the reports and its cutomization.
Regards,
Trad

High Avg Response time for logon requests via CMS

Hi Team ,
We are continuously receiving observing high Average reponse time for logon requests to the BO system via Central Management Server.
We observe response time up to 25043 ms .
Currently we are on SAP BO 4.0 SP7 patch 9 (4.0.7.9)
DB = SQL server 2008 R2
App Server = SAP NW 7.31 SP 7.
Also the size of our CMS DB is around 15 GB .
What could be the possible reasons ?
Regards ,
Abhinav

Hi Abhinav,
As one of the issues has been raised as a bug which is resolved in BI 4.1 so you can upgrade to resolve this bug. Also if the CMS database size is large then CMS has to search for objects through huge number of rows hence that will affect overall performance. So you can try to reduce this size as per my previous upate.
Apart this you can try following steps
Try to ping CMS DB server from BO servers and confirm the response is coming in 1 ms. Run tracert <DB servers name> from CMD and check the number of hops. If response time is not 1 ms or there are more number of hops then ask your network team to resolve network latency issue
You can increase the "System database connections" for each CMS from server properties. It is set to 14 by default which means the CMS will establish 14 connections to CMS database at any time. You can increase this value, however please make sure that the system database allows more connections than default 14 from DB side. This needs to be confirmed from your DBA.
Please add CMS cluster members in platformservices.properties file under Tomcat folder. Please refer following SAP KBA for steps to add the cluster members
       http://service.sap.com/sap/support/notes/1668515
       http://service.sap.com/sap/support/notes/1766935
   4. Also please confirm number of users simultaneously login to system at peak time. Usually one           CMS is capable of handling around 500 requests. So if you have more then 1000 users then add           another new CMS on same nodes if there is enough free memory on the server
Regards,
Hrishikesh

Average Response Time ASM

Hi,
Installed 10g RAC SE on Enterprise Linux 64. We have two ASM instances with 2 disk groups DATA and FRA. Database Control reports for disk group DATA (that consists of 3 RAID 5 vol.) that Average Response Time is 54-58 ms. Read Response Time is around 40-45ms. Everything is done to Oracle recommendations with a large stripe size and so on. We don't have performance problem but should not the response time be better? Can someone else share response time values for comparison?
Regards Lars

Grid Control always has been notoriously bad at measuring I/O performance of ASM, sadly. The service time numbers are usually high, and the IOPs numbers often are not IOPs so much as "I/Os to date with periodic resets to zero" numbers.
As the previous poster said, use iostat. On Linux, iostat -x, the svctm column.

Incorrect Alerts CPU Time and Average Response Time

BUG
My Alert on Web app is consistently behaving incorrectly.
If I set an alert to monitor CPU Time at threshold 1.5 seconds, it's actually set to 1.5 milliseconds even though the graph shows a dotted red line at 1.5 seconds. The alert will trigger at 1.5 milliseconds threshold. So, instead, I have to set threshold
to 1500 seconds - the graph is completely useless showing a red dotted line at ~24 mins but the alert does then go off when CPU time goes above 1500 ms (aka 1.5 seconds).
The original portal alert seems to be fine - this problem is on new portal only. Unaffected by browser type - all browsers do the same thing (Just has to be said before someone asks).
This seems to apply to all metrics using seconds (Average Response Time acts in the same way)

Hii...
Am sure you are much aware " Components Response Time spectrum"
########Analyzing Performance Problems#################
--High wait time: Insufficient number of free work processes
--High roll-wait time: Communication problem with GUI, external system,
or large amount of data requested
--High load and generation time: SAP buffers (Program, CUA or Screen)
too small
--High database request time: CPU/memory bottleneck on database server;
communication problem with database server, expensive SQL statements,
database locks, missing indexes, missing statistics or small database buffer(s)
--High CPU time: Expensive ABAP processing, for example, processing
large tables; inefficient programming
--Processing time more than twice CPU time: CPU bottlenecks
If time aloows look at
Note 0000008963 - Definition of SAP response time/processing time/CPU time
Rgds

Strange response time for an RFC call viewed from STAD on R/3 4.7

Hello,
On our R/3 4.7 production system, we have a lot of external RFC calls to execute an abap module function. There are 70 000 of these calls per day.
The mean response time for this RFC call is 35 ms.
Some times a few of them (maybe 10 to 20 per day) are way much longer.
I am currently analysing with STAD one of these long calls which lasted 10 seconds !
Here is the info from STAD
Response time :                10 683 ms
Total time in workprocess : 10 683 ms
CPU time :                               0 ms
RFC+CPIC time :                       0 ms
Wait for work process           0 ms
Processing time           10.679 ms
Load time                            1 ms
Generating time                   0 ms
Roll (in) time                        0 ms
Database request time         3 ms
Enqueue time                      0 ms
Number      Roll ins            0
                 Roll outs           0
                 Enqueues         0
Load time   Program             1 ms
                  Screen              0 ms
                 CUA interf.          0 ms
Roll time    Out                 0 ms
                  In                  0 ms
                Wait                0 ms
Frontend    No.roundtrips       0
                  GUI time            0 ms
                  Net time            0 ms
There is nearly no abap processing in the function module.
I really don't uderstand what is this 10 679 ms processing time especially with 0 ms cpu time and 0 ms wait time.
A usual fast RFC call gives this data
23 ms response time
16 ms cpu time
14 ms processing time
1 ms load time
8 ms Database request time
Does anybody have an idea of what is the system doing during the 10 seconds processing time ?
Regards,
Olivier

Hi Graham,
Thank you for your input and thoughts.
I will have to investigate on RZ23N and RZ21 because I'm not used to use them.
I'm used to investigate performance problems with ST03 and STAD.
My system is R/3 4.7 WAS 6.20. ABAP and BASIS 43
Kernel 6.40 patch level 109
We know these are old patch levels but we are not allowed to stop this system for upgrade "if it's not broken" as it is used 7/7 24/24.
I'm nearlly sure that the problem is not an RFC issue because I've found other slow dialog steps for web service calls and even for a SAPSYS technical dialog step of type <no buffer>. (what is this ?)
This SAPSYS dialog step has the following data :
User : SAPSYS
Task type : B
Program : <no buffer>
CPU time                       0 ms
RFC+CPIC time              0 ms
Total time in workprocs    5.490 ms
Response time               5.490 ms
Wait for work process           0 ms
Processing time             5.489 ms
Load time                            0 ms
Generating time                   0 ms
Roll (in+wait) time                0 ms
Database request time          1 ms ( 3 Database requests)
Enqueue time                       0 ms
All hundreds of other SAPSYS <no buffer> steps have a less than 5 ms response time.
It looks like the system was frozen during 5 seconds...
Here are some extracts from STAD of another case from last saturday.
11:00:03     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     13     13     0     0
11:00:03     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:04     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     16
11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     77     77     0     16
11:00:04     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:04     bt1sqkvf_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     16
11:00:05     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     16
11:00:05     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     53     53     0     0
11:00:06     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     76     76     0     0
11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     20     20     0     31
11:00:06     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     12     12     0     0
11:00:06     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     13     13     0     0
11:00:06     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     34     34     0     16
11:00:07     bt1sqkvh_PLG_18      RFC     R     0     USER_LECDIS     15     15     0     0
11:00:07     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     13     13     0     16
11:00:07     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     19     19     0     0
11:00:07     bt1fsaplpr02_PLG RFC     R     3     USER_LECKIT     23     13     10     0
11:00:07     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     38     38     0     0
11:00:08     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     20     20     0     16
11:00:09     bt1sqkvg_PLG_18      RFC     R     0     USER_LECDIS     9 495     9 495     0     16
11:00:09     bt1sqk2t_PLG_18      RFC     R     0     USER_LECDIS     9 404     9 404     0     0
11:00:09     bt1sqkvh_PLG_18      RFC     R     1     USER_LECKIT     9 181     9 181     0     0
11:00:10     bt1fsaplpr02_PLG RFC     R     3     USER_LECDIS     23     23     0     0
11:00:10     bt1sqkve_PLG_18      RFC     R     4     USER_LECKIT     8 465     8 465     0     16
11:00:18     bt1sqkvh_PLG_18      RFC     R     0     USER_LECKIT     18     18     0     16
11:00:18     bt1sqkvg_PLG_18      RFC     R     0     USER_LECKIT     89     89     0     0
11:00:18     bt1sqk2t_PLG_18      RFC     R     0     USER_LECKIT     75     75     0     0
11:00:18     bt1sqkvh_PLG_18      RFC     R     1     USER_LECDIS     43     43     0     0
11:00:18     bt1sqk2t_PLG_18      RFC     R     1     USER_LECDIS     32     32     0     16
11:00:18     bt1sqkvg_PLG_18      RFC     R     1     USER_LECDIS     15     15     0     16
11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     13     13     0     0
11:00:18     bt1sqkve_PLG_18      RFC     R     4     USER_LECDIS     14     14     0     0
11:00:18     bt1sqkvf_PLG_18      RFC     R     4     USER_LECKIT     69     69     0     16
11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     49     49     0     16
11:00:18     bt1sqkve_PLG_18     RFC     R     5     USER_LECKIT     19     19     0     16
11:00:18     bt1sqkvf_PLG_18     RFC     R     5     USER_LECDIS     15     15     0     16
The load at that time was very light with only a few jobs starting :
11:00:08 bt1fsaplpr02_PLG RSCONN01                     B 31 USER_BATCH     39
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 31 USER_BATCH     34
11:00:08 bt1fsaplpr02_PLG /SDF/RSORAVSH                B 33 USER_BATCH     64
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 33 USER_BATCH     43
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 34 USER_BATCH     34
11:00:08 bt1fsaplpr02_PLG RSBTCRTE                     B 35 USER_BATCH     37
11:00:09 bt1fsaplpr02_PLG RVV50R10C                    B 34 USER_BATCH     60
11:00:09 bt1fsaplpr02_PLG ZLM_HDS_IS_PURGE_RESERVATION B 35 USER_BATCH    206
I'm thinking also now about the message server as there is load balancing for each RFC call ?
Regards,
Olivier

Average response Time

All,
What is the ideal Avg Response Time for a System?
Is there any formula to calculate?
What does SAP reccomend?

Dear Bidwan,
Response time for dialog process is <b>generally based on sum of wait timeroll in timeload generation timeprocessing timelock time+db request time</b> and is measured at the application server level.
U can get these values from ST03(N) transaction.
Response time will differ for different systems, there is no such thing as ideal response time. System can be tuned to get any value for response time based on system resources and system load.
reward points if usefull.
Awaiz.

Average Response Times for a Reports Server

Similar Messages

Maybe you are looking for