BCS high response time

Hi Frns,
We are currently struggling with high response time in our BCS production system, it ranges anywhere in between 3000-15000 ms. I want to ask:
1) If there is any project running where BCS has been deployed and what response time they are recording?
2) What is the ideal RT for BCS?
3) We have also observed that UCMON00 and UCWB_INT00 transaction/report in dialog mode are responsible for such high response time, is there any alternative or solution in this area?
Environment
AIX :6.1
SEM-BW/FINBASIS : 602 patch level 13.
DB: ORACLE 11.2.0.2.0
Please let me know your suggestions to turn down response time.
Regards,
Mridul Gupta

Hi Mridul Gupta
Could you please explain where you find the response time has juge.
1. If response time on UCMON log in --> depend on Cons unit hierarchy and the task maintained
2. Response time on tranport --> Depend on the master data and hierarchy maintained in BW and quantity of data moving from Dev to Quality and to Prod
3. Response time on Process chain --> Which process chain variant tooks more time and we can find the information uncer UC_STAT0.
Like mentioned above there are so many different scenarios and also check with Basis team to compare with all your system landscape.
Regards
Rajesh SVN
Assigning points is the way of saying thank you on SCN, even if you choose correct answer or helpful answer,

Similar Messages

SQL tune (High response time)

Hi,
I am writing the following function which is causing high response time. Can you please help? Please SBMS_SQLTUNE advise.
GENERAL INFORMATION SECTION
Tuning Task Name : BFG_TUNING1
Tuning Task Owner : ARADMIN
Scope : COMPREHENSIVE
Time Limit(seconds) : 60
Completion Status : COMPLETED
Started at : 01/28/2013 15:48:39
Completed at : 01/28/2013 15:49:43
Number of SQL Restructure Findings: 7
Number of Errors : 1
Schema Name: ARADMIN
SQL ID : 2d61kbs9vpvp6
SQL Text : SELECT /*+no_merge(chg)*/ chg.CHANGE_REFERENCE,
chg.Customer_Name, chg.Customer_ID, chg.Contract_ID,
chg.Change_Title, chg.Change_Type, chg.Change_Description,
chg.Risk, chg.Impact, chg.Urgency, chg.Scheduled_Start_Date,
chg.Scheduled_End_Date, chg.Scheduled_Start_Date_Int,
chg.Scheduled_End_Date_Int, chg.Outage_Required,
chg.Change_Status, chg.Change_Status_IM, chg.Reason_for_change,
chg.Customer_Visible, chg.Change_Source,
chg.Related_Ticket_Type, chg.Related_Ticket_ID,
chg.Requested_By, chg.Requested_For, chg.Site_ID, chg.Site_Name,
chg.Element_id, chg.Element_Type, chg.Element_Name,
chg.Search_flag, chg.remedy_id, chg.Change_Manager,
chg.Email_Manager, chg.Queue, a.customer as CUSTOMER_IM,
a.contract as CONTRACT_IM, a.cid FROM exp_cm_cusid1 a, (sELECT *
FROM EXP_BFG_CM_JOIN_V WHERE CUSTOMER_ID = 14187) chg WHERE
a.bfg_con_id IS NULL AND a.bfg_cus_id = chg.customer_id AND
NOT EXISTS (SELECT a.bfg_con_id FROM exp_cm_cusid1 a WHERE
a.bfg_con_id IS NOT NULL AND a.bfg_cus_id = chg.customer_id
AND a.bfg_con_id = chg.contract_id ) UNION SELECT
/*+no_marge(chg)*/ chg.CHANGE_REFERENCE, chg.Customer_Name,
chg.Customer_ID, chg.Contract_ID, chg.Change_Title,
chg.Change_Type, chg.Change_Description, chg.Risk, chg.Impact,
chg.Urgency, chg.Scheduled_Start_Date, chg.Scheduled_End_Date,
chg.Scheduled_Start_Date_Int, chg.Scheduled_End_Date_Int,
chg.Outage_Required, chg.Change_Status, chg.Change_Status_IM,
chg.Reason_for_change, chg.Customer_Visible, chg.Change_Source,
chg.Related_Ticket_Type, chg.Related_Ticket_ID,
chg.Requested_By, chg.Requested_For, chg.Site_ID, chg.Site_Name,
chg.Element_id, chg.Element_Type, chg.Element_Name,
chg.Search_flag, chg.remedy_id, chg.Change_Manager,
chg.Email_Manager, chg.Queue, a.customer as CUSTOMER_IM,
a.contract as CONTRACT_IM, a.cid FROM exp_cm_cusid1 a, (sELECT *
FROM EXP_BFG_CM_JOIN_V WHERE CUSTOMER_ID = 14187) chg WHERE
a.bfg_cus_id = chg.customer_id AND a.bfg_con_id =
chg.contract_id AND a.bfg_con_id IS NOT NULL
FINDINGS SECTION (7 findings)
1- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 26 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
2- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 26 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
3- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 10 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
4- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 10 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
5- Restructure SQL finding (see plan 1 in explain plans section)
The predicate REGEXP_LIKE ("T100"."C536871160",'^[[:digit:]]+$') used at
line ID 6 of the execution plan contains an expression on indexed column
"C536871160". This expression prevents the optimizer from selecting indices
on table "ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
6- Restructure SQL finding (see plan 1 in explain plans section)
The predicate TO_NUMBER(TRIM("T100"."C536871160"))=:B1 used at line ID 6 of
the execution plan contains an expression on indexed column "C536871160".
This expression prevents the optimizer from selecting indices on table
"ARADMIN"."T100".
Recommendation
- Rewrite the predicate into an equivalent form to take advantage of
indices. Alternatively, create a function-based index on the expression.
Rationale
The optimizer is unable to use an index if the predicate is an inequality
condition or if there is an expression or an implicit data type conversion
on the indexed column.
7- Restructure SQL finding (see plan 1 in explain plans section)
An expensive "UNION" operation was found at line ID 1 of the execution plan.
Recommendation
- Consider using "UNION ALL" instead of "UNION", if duplicates are allowed
or uniqueness is guaranteed.
Rationale
"UNION" is an expensive and blocking operation because it requires
elimination of duplicate rows. "UNION ALL" is a cheaper alternative,
assuming that duplicates are allowed or uniqueness is guaranteed.
ERRORS SECTION
- The current operation was interrupted because it timed out.
EXPLAIN PLANS SECTION
1- Original
Plan hash value: 1047651452
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 2 | 28290 | 567 (37)| 00:00:07 | | |
| 1 | SORT UNIQUE | | 2 | 28290 | 567 (37)| 00:00:07 | | |
| 2 | UNION-ALL | | | | | | | |
|* 3 | HASH JOIN RIGHT ANTI | | 1 | 14158 | 373 (5)| 00:00:05 | | |
| 4 | VIEW | VW_SQ_1 | 1 | 26 | 179 (3)| 00:00:03 | | |
| 5 | NESTED LOOPS | | 1 | 37 | 179 (3)| 00:00:03 | | |
|* 6 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
|* 7 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | 9 | 1 (0)| 00:00:01 | | |
| 8 | NESTED LOOPS | | 1 | 14132 | 193 (5)| 00:00:03 | | |
|* 9 | HASH JOIN | | 1 | 14085 | 192 (5)| 00:00:03 | | |
|* 10 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
| 11 | VIEW | EXP_BFG_CM_JOIN_V | 3 | 42171 | 13 (24)| 00:00:01 | | |
| 12 | UNION-ALL | | | | | | | |
|* 13 | HASH JOIN | | 1 | 6389 | 5 (20)| 00:00:01 | | |
| 14 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 15 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 410 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 16 | HASH UNIQUE | | 1 | 6052 | 6 (34)| 00:00:01 | | |
|* 17 | HASH JOIN | | 1 | 6052 | 5 (20)| 00:00:01 | | |
| 18 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 19 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 73 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 20 | HASH UNIQUE | | 1 | 5979 | 3 (34)| 00:00:01 | | |
| 21 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 22 | TABLE ACCESS BY INDEX ROWID| T1451 | 1 | 47 | 1 (0)| 00:00:01 | | |
|* 23 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | | 1 (0)| 00:00:01 | | |
| 24 | NESTED LOOPS | | 1 | 14132 | 193 (5)| 00:00:03 | | |
|* 25 | HASH JOIN | | 1 | 14085 | 192 (5)| 00:00:03 | | |
|* 26 | TABLE ACCESS FULL | T100 | 1 | 28 | 178 (3)| 00:00:03 | | |
| 27 | VIEW | EXP_BFG_CM_JOIN_V | 3 | 42171 | 13 (24)| 00:00:01 | | |
| 28 | UNION-ALL | | | | | | | |
|* 29 | HASH JOIN | | 1 | 6389 | 5 (20)| 00:00:01 | | |
| 30 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 31 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 410 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 32 | HASH UNIQUE | | 1 | 6052 | 6 (34)| 00:00:01 | | |
|* 33 | HASH JOIN | | 1 | 6052 | 5 (20)| 00:00:01 | | |
| 34 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 35 | REMOTE | PROP_CHANGE_INVENTORY_V | 1 | 73 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 36 | HASH UNIQUE | | 1 | 5979 | 3 (34)| 00:00:01 | | |
| 37 | REMOTE | PROP_CHANGE_REQUEST_V | 1 | 5979 | 2 (0)| 00:00:01 | ARS_B~ | R->S |
| 38 | TABLE ACCESS BY INDEX ROWID | T1451 | 1 | 47 | 1 (0)| 00:00:01 | | |
|* 39 | INDEX RANGE SCAN | I1451_536870913_1 | 1 | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
3 - access("ITEM_0"="EXP_BFG_CM_JOIN_V"."CUSTOMER_ID" AND "ITEM_1"="EXP_BFG_CM_JOIN_V"."CONTRACT_ID")
6 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NOT NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_0 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
7 - access("C536870913"="C536870914")
9 - access("EXP_BFG_CM_JOIN_V"."CUSTOMER_ID"=TO_NUMBER(TRIM("C536871160")))
10 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_0 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
13 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
17 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
23 - access("C536870913"="C536870914")
25 - access("EXP_BFG_CM_JOIN_V"."CUSTOMER_ID"=TO_NUMBER(TRIM("C536871160")) AND
"EXP_BFG_CM_JOIN_V"."CONTRACT_ID"=TO_NUMBER(TRIM("C536871088")))
26 - filter("C536871050" LIKE '%FMS%' AND REGEXP_LIKE ("C536871160",'^[[:digit:]]+$') AND ("C536871088" IS NULL
OR REGEXP_LIKE ("C536871088",'^[[:digit:]]+$')) AND TO_NUMBER(TRIM("C536871088")) IS NOT NULL AND
TO_NUMBER(TRIM("C536871160"))=:SYS_B_1 AND "C536871160" IS NOT NULL AND "C536871050" IS NOT NULL AND "C7"=0)
29 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
33 - access("CHG"."PRP_CHG_REFERENCE"="INV"."PRP_CHG_REFERENCE")
39 - access("C536870913"="C536870914")
Remote SQL Information (identified by operation id):
14 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
15 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME","ELEMENT_SUMMARY","PRODUCT_NAME" FROM
"PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV" (accessing 'ARS_BFG_DBLINK.WORLD' )
18 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
19 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME" FROM "PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV"
(accessing 'ARS_BFG_DBLINK.WORLD' )
21 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
30 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
31 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME","ELEMENT_SUMMARY","PRODUCT_NAME" FROM
"PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV" (accessing 'ARS_BFG_DBLINK.WORLD' )
34 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
35 - SELECT "PRP_CHG_REFERENCE","SIT_ID","SIT_NAME" FROM "PROP_OWNER2"."PROP_CHANGE_INVENTORY_V" "INV"
(accessing 'ARS_BFG_DBLINK.WORLD' )
37 - SELECT "PRP_CHG_REFERENCE","CUS_ID","CUS_NAME","CNT_BFG_ID","PRP_TITLE","PRP_CHG_TYPE","PRP_DESCRIPTION","PR
P_BTIGNITE_PRIORITY","PRP_CUSTOMER_PRIORITY","PRP_CHG_URGENCY","PRP_RESPONSE_REQUIRED_BY","PRP_REQUIRED_BY_DATE","P
RP_CHG_OUTAGE_FLAG","PRP_CHG_STATUS","PRP_CHG_FOR_REASON","PRP_CHG_CUSTOMER_VISIBILITY","PRP_CHG_SOURCE_SYSTEM","PR
P_RELATED_TICKET_TYPE","PRP_RELATED_TICKET_ID","CHANGE_INITIATOR","CHANGE_ORIGINATOR","CHANGE_MANAGER","QUEUE"
FROM "PROP_OWNER2"."PROP_CHANGE_REQUEST_V" "CHG" WHERE "CUS_ID"=:1 (accessing 'ARS_BFG_DBLINK.WORLD' )
-------------------------------------------------------------------------------

Please review the following threads:
{message:id=9360002}
{message:id=9360003}

Webgui and high response time

Hi guys,
we have upgraded our worktation to windows 7 with IE9. Our users complains high response time after migration.
We have tested the webgui with Win 7 and IE8 and the response time is accetable, but we can't downgrade the IE version.
We have tried to setup the compatibility with IE8 , but the issue persist.
Do you have any suggestion about resolve the issue ?
thank's in advance fro your help.
Antonino

What is your SAP MII version?
While loading webpage, is it showing contentiously loading and not opening content, then its 100% java issue only.
Goto IE9-->Tools-->internet options --> Advanced --> Browsing check(Disable script debugging). Once you down this, on status bar its shows the error like 'undefined object'.
To correct it, you need to upgrade or degrade java version accordingly.
Mine is Window 7 and using Java version 1.7.0_13-b20. its working fine.
Regards,
Praveen Reddy

High Response Time : Weblogic v8.1

Our application performs really bad in our production environment. Same code running on a different server (TEST or QA) is better. QA is bad when compared to TEST. Inside HTML there are references to images, css, js and the fetch times as reported in firebug (firefox) for each one of them is around 1300 ms in PROD. QA is around 700 ms and TEST less than 400 ms. PROD server is in not in the same building as TEST And QA. But there are other applications on the same box and their response time is less than 400 ms. So it is not the machine but it is a problem with application or webserver set up. We also timed using "wget" of linux to bypass browser and still notice the same high response times. There is no encryption or any form of SSL here. Ping with 4K size is in the range of 30 ms in PROD compared to 10-20 in QA.
What can we check to make sure there are no obvious set up errors in our case?

What supervisor are you running ?
Be aware that the 6548 module is quite heavily oversubscribed and you could be running into this ie. servers will definitely be sending a lot more data than an IP phone.
The 6548 has an 8Gbps connection the switch fabric (note this is assuming a sup 720). So you have 48 1Gbps ports going in (in = from end devices) and only 8Gbps going out (out = to the switch fabric). Each group of 6 ports shares a 1Gbps connection the switch fabric. So lets says on one of those groupings you had 6 servers with 1Gbps connections. If only three of these servers were sending out 400Mbps of data each you have contention because 3 x 400Mbps = 1.2Gbps and you only have 1Gbps to the switch fabric.
If this is the problem there are a couple of solutions -
1) you can look into how the devices are spread across the port groupings and maybe you could move things around to make the traffic more even among port groupings. However you mention servers and trunks so you could just end up with the same problem but also the phones are not working either.
2) you can look to migrate some connections off that module onto another but this supposes you have spare capacity elsewhere. If those trunk links are connected to other switches then you would defintely want to look into moving these as the 6548 was never intended to be used as an uplink module between switches.
3) you could upgrade the module to something like a 6748 (or whatever the latest is as they keep introducing new ones) which has a much better connection to the switch fabric. Again this assumes a sup720 as the 6748 would't work with a sup32.
However don't just rush into 3) without first doing some investigation work eg. what do the servers do, how much traffic are they churning out etc. Have you looked at the interface stats for each connection to see if you are getting drops etc ?
Jon

How to find the top ten reports consuming the high response times in st03n?

HI Basis Gurus,
Please could anybody tell me "How can one find the top ten high response time consuming reports in st03n transaction or in is there any other way to find out this.Please help me its urgent....
Advance thanks....

hi Meghadoot,
below is an example for your request.
ST03N
Expert mode
Server name - Day- double clicdk Today
In analysis view - Ranking lists-double click Top Response time
Regards

High response time on one line card in Cisco 6513 Catalyst Switch

I am facing a wierd issue with one of the line card in the Cisco 6513 switch. All the servers, desktops and trunks connected to this line card are showing high response time (>500ms) locally. But those IP phones connected to the same line card is working fine and the repsonse time is always 1ms. I am unable to find any root cause as i am not seeing any errors or logs, please help me to fidn the root cause.
Anyway i ahve a plan to reboot the line card and test it, but i am just looking for a fix that would help us to avoid the reboot.
The affected module is WS-X6548-GE-TX.
No errors for the following commands.
#sh fabric status
#sh fabric error
#sh module all
#sh module <slot>
#sh interface counter errors
#sh version:
Cisco Internetwork Operating System Software IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1)
Compiled Fri 14-Sep-07 21:50 by kellythw
Image text-base: 0x40101040, data-base: 0x42DB89D0
ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
BOOTLDR: s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1)
CISCOCORE-6513 uptime is 4 weeks, 4 days, 18 hours, 35 minutes
Time since CISCOCORE-6513 switched to active is 4 weeks, 4 days, 18 hours, 34 minutes
System returned to ROM by reload at 04:33:29 UTC Fri Feb 22 2013 (SP by reload)
System image file is "sup-bootdisk:s72033-ipservicesk9_wan-mz.122-18.SXF11.bin"
cisco WS-C6513 (R7000) processor (revision 1.0) with 458720K/65536K bytes of memory.
Processor board ID SAL09507GV9
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
SuperLAT software (copyright 1990 by Meridian Technology Corp).
X.25 software, Version 3.0.0.
Bridging software.
TN3270 Emulation software.
15 Virtual Ethernet/IEEE 802.3 interfaces
172 Gigabit Ethernet/IEEE 802.3 interfaces
4 Ten Gigabit Ethernet/IEEE 802.3 interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.
65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

What supervisor are you running ?
Be aware that the 6548 module is quite heavily oversubscribed and you could be running into this ie. servers will definitely be sending a lot more data than an IP phone.
The 6548 has an 8Gbps connection the switch fabric (note this is assuming a sup 720). So you have 48 1Gbps ports going in (in = from end devices) and only 8Gbps going out (out = to the switch fabric). Each group of 6 ports shares a 1Gbps connection the switch fabric. So lets says on one of those groupings you had 6 servers with 1Gbps connections. If only three of these servers were sending out 400Mbps of data each you have contention because 3 x 400Mbps = 1.2Gbps and you only have 1Gbps to the switch fabric.
If this is the problem there are a couple of solutions -
1) you can look into how the devices are spread across the port groupings and maybe you could move things around to make the traffic more even among port groupings. However you mention servers and trunks so you could just end up with the same problem but also the phones are not working either.
2) you can look to migrate some connections off that module onto another but this supposes you have spare capacity elsewhere. If those trunk links are connected to other switches then you would defintely want to look into moving these as the 6548 was never intended to be used as an uplink module between switches.
3) you could upgrade the module to something like a 6748 (or whatever the latest is as they keep introducing new ones) which has a much better connection to the switch fabric. Again this assumes a sup720 as the 6748 would't work with a sup32.
However don't just rush into 3) without first doing some investigation work eg. what do the servers do, how much traffic are they churning out etc. Have you looked at the interface stats for each connection to see if you are getting drops etc ?
Jon

Hard drive passes all tests but extremely high response times causing major performance issues.

I have a HP Compaq Presario CQ62-360TX pre-loaded with Windows 7 home premium (64-bit) that I purchased just under a year ago.
Recently my experience has been interrupted by stuttering that ranges from annoying in general use to a major headache when playing music or videos from the hard drive.
The problem appears to be being caused by extremely hard drive high response times (up to 10 seconds). As far as I know I didn't install anything that might have caused the problems before this happened, and I can't find anything of note looking back through event viewer.
In response to this I've run multiple hard drive scans for problems (chkdsk, scandsk, test through BIOS, test through HP software and others) all of which have passed with no problems. The only thing of any note is a caution on crystaldiskinfo due to the reallocated sector count but as none of the other tests have reported bad sectors I'm unsure as to whether this is causing the problem. I've also updated drivers for my Intel 5 Series 4 Port SATA AHCI Controller from the Intel website and my BIOS from HP as well as various other drivers (sound, video etc), as far as I can tell there are none available for my hard drive directly. I've also wanted to mess with the hard drive settings in the BIOS but it appears those options are not available to me even in the latest version.
System Specs:
Processor: Intel(R) Pentium(R) CPU P6100 @ 2.00GHz (2 CPUs), ~2.0GHz
Memory: 2048MB RAM
Video Card: ATI Mobility Radeon HD 5400 Series
Sound Card: ASUS Xonar U3 Audio Device or Realtek High Definition Audio (both have problem)
Hard Drive: Toshiba MK5065GSK
Any ideas?
Edit: The drive is nowhere near full, it's not badly fragmented and as far as I can tell there's no virus or malware.

Sounds like failing sectors are being replaced with good spares sucessfully so far, this is done on the fly and will not show in any test, you have a failing drive, I would back up your data and replace the hard drive.
Sector replacement on the fly explains the poor performance also, replacing sectors with spares is normal if it is just a few over many years, but crystal is warning you there are too many, a sign of drive failure is around the corner.

Explain plan - lower cost but higher response time in 11g compared to 10g

Hello,
I have a strange scenario where 'm migrating a db from standalone Sun FS running 10g RDBMS to a 2-Node Sun/ASM 11g RAC env. The issue is with response time of queries -
In 11g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANALYZED NUM_ROWS
11-08-2012 18:21:12 3413956
Elapsed: 00:00:00.30
In 10g Env:
SQL> select last_analyzed, num_rows from dba_tables where owner='MARKETHEALTH' and table_name='NCP_DETAIL_TAB';
LAST_ANAL NUM_ROWS
07-NOV-12 3502160
Elapsed: 00:00:00.04If you look @ the response times, even a simple query on the dba_tables takes ~8 times. Any ideas what might be causing this? I have compared the XPlans and they are exactly the same, moreover, the cost is less in the 11g env compared to the 10g env, but still the response time is higher.
BTW - 'm running the queries directly on the server, so no network latency in play here.
Thanks in advance
aBBy.

*11g Env:*
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1104 | 376K| 394 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1104 | 376K| 394 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1104 | 376K| 393 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1136 | | 15 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
*10g Env:*
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4147636274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1137 | 373K| 389 (1)| 00:00:05 |
| 1 | SORT ORDER BY | | 1137 | 373K| 389 (1)| 00:00:05 |
| 2 | TABLE ACCESS BY INDEX ROWID| NCP_DETAIL_TAB | 1137 | 373K| 388 (1)| 00:00:05 |
|* 3 | INDEX RANGE SCAN | IDX_NCP_DET_TAB_US | 1137 | | 15 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("UNIT_ID"='ten03.burien.wa.seattle.comcast.net')
15 rows selected.
The query used is:
explain plan for
select
NCP_DETAIL_ID ,
NCP_ID ,
STATUS_ID ,
FIBER_NODE ,
NODE_DESC ,
GL ,
FTA_ID ,
OLD_BUS_ID ,
VIRTUAL_NODE_IND ,
SERVICE_DELIVERY_TYPE ,
HHP_AUDIT_QTY ,
COMMUNITY_SERVED ,
CMTS_CARD_ID ,
OPTICAL_TRANSMITTER ,
OPTICAL_RECEIVER ,
LASER_GROUP_ID ,
UNIT_ID ,
DS_SLOT ,
DOWNSTREAM_PORT_ID ,
DS_PORT_OR_MOD_RF_CHAN ,
DOWNSTREAM_FREQ ,
DOWNSTREAM_MODULATION ,
UPSTREAM_PORT_ID ,
UPSTREAM_PORT ,
UPSTREAM_FREQ ,
UPSTREAM_MODULATION ,
UPSTREAM_WIDTH ,
UPSTREAM_LOGICAL_PORT ,
UPSTREAM_PHYSICAL_PORT ,
NCP_DETAIL_COMMENTS ,
ROW_CHANGE_IND ,
STATUS_DATE ,
STATUS_USER ,
MODEM_COUNT ,
NODE_ID ,
NODE_FIELD_ID ,
CREATE_USER ,
CREATE_DT ,
LAST_CHANGE_USER ,
LAST_CHANGE_DT ,
UNIT_ID_IP ,
US_SLOT ,
MOD_RF_CHAN_ID ,
DOWNSTREAM_LOGICAL_PORT ,
STATE
from markethealth.NCP_DETAIL_TAB
WHERE UNIT_ID = :B1
ORDER BY UNIT_ID, DS_SLOT, DS_PORT_OR_MOD_RF_CHAN, FIBER_NODE
This is the query used for Query 1.
Stats differences are:
1. Rownum differes by apprx - 90K more rows in 10g env
2. RAC env has 4 additional columns (excluded in the select statement for analysis purposes).
3. Gather Stats was performed with estimate_percent = 20 in 10g and estimate_percent = 50 in 11g.

SG200-26P [FW-1.1.2.0] - Very High Response Time: 1000ms!

Hello,
Problem: New SG-200 26P Smart Switch with Latest Firmware - Very High Responce Time 500-800ms
We've a EdgeMarc 4500 Router with 10 VPN tunnels to 10 brach locations. SG-200 26P Smart Switch is connected to 7 Servers (2 Terminal, SQL, and Other) All locations have 50MB Download and 20MB Upload speed from Verizon FiOS Internet service.
As per the SolarWind tool, the response time of this switch is around at 500ms. At the same time, the EdgeMarc 4500 router response time is around 40ms and less.
We've 60 desktops remotely connected to our SQL Server database and 40 RDP Users via Remote Desktop. The configuration is same from past 3 years. But we change the switch from HP 1800-24G to Cisco due to some Connection Failures. For Connection Failures, we first suspect the old HP switch, but it's look like issue with EdgeMarc Router.
Is this Response Time is normal? I attached two screenshots of both Cisco Switch and EdgeMarc Router Response Time from past 24 hours according to SolarWind tool. Any further advice would be greatly appreciated. Thank you.

Hello Srinath,
Thank you for participating in the Small Business support community. My name is Nico Muselle from Cisco Sofia SBSC.
The response time from the switch could be considered as quite normal. Reason for this is that the switch gives CPU priority to it's actual duties which would of course be switching, access lists, VLANs, QoS, multicast and DHCP snooping etc etc. As a result of that, ping response times of the switch itself do not show in any way the correct working of the switch.
I invite you to try pinging clients connected to the switch, you should be able to notice that response times to the clients are a lot lower than response times of the switch itself.
Hope this answers your question !
Best regards,
Nico Muselle
Sr. Network Engineer - CCNA - CCNA Security

Tnsping, high response time

Hi,
i've a cluster 11gr2 that start a virtual ip used for a listener.
tnsping response time is very high:
Attempting to contact (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=10.2.213.4)
(PORT=1521)) (CONNECT_DATA= (SID=ORCL)))
OK (1680 msec)My db (9i r2) show me some wait time like this:
SQL*Net message from dblink 6,827 249 6.12
SQL*Net more data to client 156,071 61 1.50I think that is a network problem but i don't know where can i look for.
tnx

Here is a tnsping with cycle:
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (10 msec)
OK (300 msec)
OK (870 msec)
OK (1200 msec)
OK (1300 msec)
OK (400 msec)
OK (320 msec)
OK (10 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (20 msec)
OK (0 msec)
OK (0 msec)on another vip listener on the same machine on the same interface i haven't this problem:
OK (0 msec)
OK (0 msec)
OK (10 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (20 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (0 msec)
OK (20 msec)

J2sdk1.4 takes higher response time in database interaction than jdk1.3

Hi All
I am working on performance issues regarding response time . i have upgraded my system from jdk1.3 to j2sdk1.4 . I was expecting the performance gain in terms of response time in j2sdk1.4. but to my surprise it shows varied results with my application. it shows that j2sdk1.4 is taking higher time for executing the application when it has to deal with database. I am using oracle 9i as the backend database server.
if any body has the idea about, why j2sdk1.4 is showing higher responce time while interacting with database as compare to jdk1.3. then do let me know this.
Thanx in advance

Hi All
I am working on performance issues regarding response time . i have upgraded my system from jdk1.3 to j2sdk1.4 . I was expecting the performance gain in terms of response time in j2sdk1.4. but to my surprise it shows varied results with my application. it shows that j2sdk1.4 is taking higher time for executing the application when it has to deal with database. I am using oracle 9i as the backend database server.
if any body has the idea about, why j2sdk1.4 is showing higher responce time while interacting with database as compare to jdk1.3. then do let me know this.
Thanx in advance

High GUI Time - Causing high Response time

Hi All,
Average GUI Response time is approx 400 ms in my ECC 6.0 system, OS - HP UX, Database - Oracle 10.2.0.5.
I expect it should always be approx 200 ms, but as it is high it is contibuting to high overall response time.
I expect there are normally two ways of high GUI time :
1) High network time between Presentation layer( User System) and Application Layer(SAP Server).
2) High amount of time in Loading User Screen
For Option 2 I have checked we are using SAP access menu so there should not any problem with loading of User Access Menu.
Average Response time for session_manager is 2 Secs.
Please suggest me what all other ways available to improve GUI time,
Can there be other reasons of high GUI time and how can we make sure that high GUI time is only because of high Network time.
Please suggest.
Shivam

I believe in case you have multiple roundtrips per step, then the client performance comes into play as well. So if you have slow clients this could be an issue too.
Basically you are already looking in the right place (network connection), but i recommend you also check:
- roundtrips per step and amount of data sent to the client
- are all transactions having high gui times, or only a few?
- how is the situation on the clients?
- if you have clients working on prod and qas check the values on the qas system too
Cheers Michael

How to Tune the Transactions/ Z - reports /Progr..of High response time

Dear friends,
in <b>ST03</b> work load anlysis menu.... there are some z-reports, transactions, and some programmes are noticed contineously that they are taking the <b>max. response time</b> (and mostly >90%of time is DB Time ).
how to tune the above situation ??
Thank u.

Siva,
You can start with some thing like:
ST04 -> Detail Analysis -> SQL Request (look at top disk reads and buffer get SQL statements)
For the top SQL statements identified you'd want to look at the explain plan to determine if the SQL statements is:
1) inefficient
2) are your DB stats up to date on the tables (note up to date stats does not always means they are the best)
3) if there are better indexes available, if not would a more suitable index help?
4) if there are many slow disk reads, is there an I/O issue?
etc...
While you're in ST04 make sure your buffers are sized adequately.
Also make sure your Oracle parameters are set according to this OSS note.
Note 830576 - Parameter recommendations for Oracle 10g

High Response Times with 50 content items in a Publisher 6.5 portlet

Folks,
Have set up a load test, running with a single user, in which new News Article content items are inserted into a Publisher 6.5 portlet created of the News Portlet template. Inserts have good response times through 25 or so content items in the portlet. Then response times become linearly longer, until it takes ten minutes to insert a content item, when there are 160 content items already.
This is a test system that is experiencing no other problems. There are no other users on the system, only the single test user in LoadRunner, inserting one content item at a time. The actual size of the content item is tiny. Memory usage in the Publisher JVM (as seein on the Diagnostics page) does not vary from 87% used with 13% free. So I asked for a DB Trace, to determine if there were long-running queries. I can provide this on request, it zips to less than 700k.
Have seldom seen this kind of linear scalability!
Looked at the trace through SQL Server Profiler. There are several items running for more than one second, the Audit Logout EventClass repeatedly occurs with long durations (ten minutes and more). The users are publisher user, workflow user, an NT user and one DatabaseMail transaction taking 286173 ms.
In most cases there is no TextData, and the ApplicationName is i-net opta 2000 (which looks like a JDBC driver) in the longest-running cases.
Nevertheless, for the short running queries, there are many (hundreds) of calls to exec sp_execute and IF @@TRANCOUNT > 0 ROLLBACK TRAN. This is most of what fills the log. This is strange because only a few records were actually inserted successfully, during the course of the test. I see numerous calls to sp_prepexec related to the main table in question, PCSCONTENTITEMS, but very short duration (no apparent problems) on the execution of the stored procedures. Completed usually within 20ms.
I am unble to tell if a session has an active request but is being blocked, or is blocking others... can anyone with SQL Server DBA knowledge help me interpret these results?
Thanks !!!
Robert

hmmm....is this the ootb news portlet? does it keep all content items in one publisher folder? if so then it is probably trying to re-publish that entire folder for every content item and choking on multiple republish executes. i dont think that ootb portlet was meant to cover a use case of multiple content item inserts so quickly. by definition newsworth stuff should not happen to need bulk inserts. is there another way to insert all of the items using publisher admin and then do one publish for all?
i know in past migration efforts when i've written utilities to migrate from legacy to publisher the inserts and saves for each item took a couple of seconds each. the publishing was done at the end and took quite a long time.

Higher response time after adding more CPU

Hello all,
have you ever experienced that after incresing SAPs (adding 2 more CPU + 4 GB of memory) on the VMware ESX 3.5 the DB response time went from 150 to 400-500 ms ? NO DB parameter were changed. In app server, only extended memory and program buffer were enlarged.
We are running ECC6 system on MAXDB 7.6.6.3 (SLES9). MAXCPU is set to 1
Any idea ?
Thank you.
Pavol
Edited by: Pavol Simko on Jul 28, 2009 10:35 AM

> We are running ECC6 system on MAXDB 7.6.6.3 (SLES9). MAXCPU is set to 1
I'd always set MAXCPU to the number of physical CPUs/cores you have. It's VERY unlikely that the database will use more CPU than the application.
The database can't scale, if one CPU is used other requests have to wait.
Markus

BCS high response time

Similar Messages

Maybe you are looking for