Transaction response time increase all of suddden

We are in peculiar situation in the oltp env of 11g.
oltp normal transaction will be completed in less than 1 second, sometime its goes up 6 seconds. we looked in awr report and in os load, there are no spikes and they are normal as previous. Application team is blame us, its problem with database. App server i.eApache configured with connection pool so i can't able do the sql trace. How to diagnose this situation? Through ash/awr report can we find any symptons. please advise..

user530956 wrote:
We are in peculiar situation in the oltp env of 11g.
oltp normal transaction will be completed in less than 1 second, sometime its goes up 6 seconds. we looked in awr report and in os load, there are no spikes and they are normal as previous. Application team is blame us, its problem with database. App server i.eApache configured with connection pool so i can't able do the sql trace. How to diagnose this situation? Through ash/awr report can we find any symptons. please advise..does SQL utilize BIND variables?

Similar Messages

  • SLR - transaction response time for all appl. servers together

    Hi,
    we want to have in SLR response time for defined transaction. We have activated necessary steps for monitoring transactions, started CPH and we can see in SLR average response times.
    We have several application servers and we want to have in SLR TOTAL response time for all appl. servers together.
    Is it possible? What is necessary steps to do it?
    Thanks for all hints.
    Regards,
    Roman

    Hi Andreas,
    Another way to approach this would be to use CCMS transaction monitoring by maintaining table ALTRAMONI (in the satellite system) as described here: http://help.sap.com/saphelp_nw70/helpdata/en/b3/468e3b093d4031e10000000a11402f/content.htm
    In RZ20 you'll be able to see the last 24 hours of performance data in a 1-hour granularity, as well as the last 30 minutes in a higher granularity.  Depending on your requirements you can then configure alerting so that you get an email when performance passes a certain threshold.
    Jon

  • Response time increase in OSB

    Dear all,
    While performing the Load test, during initial 2 - 3 hrs performance is very good. after 2 -3 hrs response time increasing and there by throughput going down 4 times.
    when i check in GC Log, i found all OC's. generally i used to find many YC's and very less OC's. but this time its deferent. not sure why this behaviour.
    Below is snap shot of my gc.log.
    Following are my startManagedweblogic java options.
    JAVA_OPTIONS="${JAVA_OPTIONS} -Xverbose:memory -Xmx:6144m -Xms:6144m -Xns:3072m -Xverbosetimestamp -Xgcprio:pausetime -Xverboselog:/usr/home/WEBADM/blq2gsbl/BLQRYSBDM/bin/gc.log -Xverbose:gcreport -XlargePages -XXgcThreads:8 -XXtlasize:min=2k,preferred=16k -XXnoSystemGC"
    please note that i have enough memory to increase till 12 gb also. i found better performance with 6g so i kept it as 6.
    [WARN ] Use of -Djrockit.optfile is deprecated and discouraged.
    [memory ][Mon Aug 12 12:34:11 2013][16261] Running with 32 bit heap and compressed references supporting 32GB heap.
    [memory ][Mon Aug 12 12:34:11 2013][16261] Using 256MB pages for Java heap.
    [memory ][Mon Aug 12 12:34:12 2013][16261] GC mode: Garbage collection optimized for short pausetimes, strategy: Generational Concurrent Mark & Sweep.
    [memory ][Mon Aug 12 12:34:12 2013][16261] Heap size: 6291456KB, maximal heap size: 6291456KB, nursery size: 3145728KB.
    [memory ][Mon Aug 12 12:34:12 2013][16261] <start>-<end>: <type> <before>KB-><after>KB (<heap>KB), <time> ms, sum of pauses <pause> ms.
    [memory ][Mon Aug 12 12:34:12 2013][16261] <start>  - start time of collection (seconds since jvm start).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <type>   - OC (old collection) or YC (young collection).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <end>    - end time of collection (seconds since jvm start).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <before> - memory used by objects before collection (KB).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <after>  - memory used by objects after collection (KB).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <heap>   - size of heap after collection (KB).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <time>   - total time of collection (milliseconds).
    [memory ][Mon Aug 12 12:34:12 2013][16261] <pause>  - total sum of pauses during collection (milliseconds).
    [memory ][Mon Aug 12 12:34:12 2013][16261]            Run with -Xverbose:gcpause to see individual phases.
    [memory ][Mon Aug 12 12:49:59 2013][16261] [YC#1] 947.689-948.011: YC 3426740KB->1274833KB (6291456KB), 0.323 s, sum of pauses 322.080 ms, longest pause 322.080 ms.
    [memory ][Mon Aug 12 12:50:18 2013][16261] [YC#2] 966.433-966.521: YC 3700241KB->1381022KB (6291456KB), 0.088 s, sum of pauses 87.355 ms, longest pause 87.355 ms.
    [memory ][Mon Aug 12 12:50:33 2013][16261] [YC#3] 981.691-981.734: YC 3806640KB->1448962KB (6291456KB), 0.043 s, sum of pauses 42.316 ms, longest pause 42.316 ms.
    [memory ][Mon Aug 12 12:50:48 2013][16261] [YC#4] 996.195-996.232: YC 3876151KB->1518729KB (6291456KB), 0.037 s, sum of pauses 36.360 ms, longest pause 36.360 ms.
    [memory ][Mon Aug 12 12:51:03 2013][16261] [YC#5] 1011.797-1011.833: YC 3950327KB->1592393KB (6291456KB), 0.036 s, sum of pauses 35.004 ms, longest pause 35.004 ms.
    [memory ][Mon Aug 12 12:51:19 2013][16261] [YC#6] 1027.447-1027.489: YC 4022805KB->1665479KB (6291456KB), 0.041 s, sum of pauses 40.711 ms, longest pause 40.711 ms.
    [memory ][Mon Aug 12 12:51:34 2013][16261] [YC#7] 1043.090-1043.127: YC 4097355KB->1739629KB (6291456KB), 0.037 s, sum of pauses 35.984 ms, longest pause 35.984 ms.
    [memory ][Mon Aug 12 12:51:50 2013][16261] [YC#8] 1058.656-1058.704: YC 4171396KB->1814054KB (6291456KB), 0.047 s, sum of pauses 46.695 ms, longest pause 46.695 ms.
    [memory ][Mon Aug 12 12:52:00 2013][16261] [YC#9] 1068.490-1068.533: YC 4245475KB->1887941KB (6291456KB), 0.043 s, sum of pauses 42.002 ms, longest pause 42.002 ms.
    [memory ][Mon Aug 12 12:52:09 2013][16261] [YC#10] 1077.381-1077.421: YC 4318167KB->1961481KB (6291456KB), 0.041 s, sum of pauses 39.592 ms, longest pause 39.592 ms.
    [memory ][Mon Aug 12 12:52:19 2013][16261] [YC#11] 1087.366-1087.406: YC 4394185KB->2036571KB (6291456KB), 0.039 s, sum of pauses 38.757 ms
    87.597 ms, longest pause 50.632 ms.
    [memory ][Tue Aug 13 18:21:28 2013][16261] [OC#9822] 107234.509-107237.018: OC 893216KB->845338KB (6291456KB), 2.509 s, sum of pauses 536.399 ms, longest pause 504.274 ms.
    [memory ][Tue Aug 13 18:21:31 2013][16261] [OC#9823] 107237.419-107239.864: OC 1116022KB->860547KB (6291456KB), 2.445 s, sum of pauses 414.935 ms, longest pause 354.974 ms.
    [memory ][Tue Aug 13 18:21:34 2013][16261] [OC#9824] 107239.864-107242.447: OC 949080KB->878533KB (6291456KB), 2.583 s, sum of pauses 541.277 ms, longest pause 504.113 ms.
    [memory ][Tue Aug 13 18:21:37 2013][16261] [OC#9825] 107242.447-107245.494: OC 953535KB->860560KB (6291456KB), 3.047 s, sum of pauses 633.955 ms, longest pause 504.806 ms.
    [memory ][Tue Aug 13 18:21:39 2013][16261] [OC#9826] 107245.494-107247.971: OC 1054631KB->869654KB (6291456KB), 2.478 s, sum of pauses 541.422 ms, longest pause 504.193 ms.
    [memory ][Tue Aug 13 18:21:42 2013][16261] [OC#9827] 107247.972-107250.441: OC 921210KB->857407KB (6291456KB), 2.469 s, sum of pauses 483.940 ms, longest pause 440.031 ms.
    [memory ][Tue Aug 13 18:21:45 2013][16261] [OC#9828] 107250.792-107253.213: OC 1132559KB->875285KB (6291456KB), 2.422 s, sum of pauses 524.526 ms, longest pause 487.132 ms.
    [memory ][Tue Aug 13 18:21:47 2013][16261] [OC#9829] 107253.213-107255.610: OC 899114KB->855957KB (6291456KB), 2.397 s, sum of pauses 481.233 ms, longest pause 451.024 ms.
    [memory ][Tue Aug 13 18:21:50 2013][16261] [OC#9830] 107256.011-107258.297: OC 1127479KB->868126KB (6291456KB), 2.286 s, sum of pauses 373.648 ms, longest pause 336.646 ms.
    [memory ][Tue Aug 13 18:21:52 2013][16261] [OC#9831] 107258.298-107260.847: OC 912365KB->856462KB (6291456KB), 2.550 s, sum of pauses 526.103 ms, longest pause 492.768 ms.
    [memory ][Tue Aug 13 18:21:55 2013][16261] [OC#9832] 107261.098-107263.611: OC 1044068KB->863005KB (6291456KB), 2.513 s, sum of pauses 541.427 ms, longest pause 504.196 ms.
    [memory ][Tue Aug 13 18:21:57 2013][16261] [OC#9833] 107263.611-107265.846: OC 902510KB->847460KB (6291456KB), 2.235 s, sum of pauses 213.535 ms, longest pause 179.799 ms.
    [memory ][Tue Aug 13 18:22:00 2013][16261] [OC#9834] 107265.946-107268.356: OC 974573KB->863254KB (6291456KB), 2.409 s, sum of pauses 441.951 ms, longest pause 405.552 ms.
    [memory ][Tue Aug 13 18:22:02 2013][16261] [OC#9835] 107268.556-107271.134: OC 1013772KB->856892KB (6291456KB), 2.578 s, sum of pauses 542.932 ms, longest pause 503.782 ms.
    [memory ][Tue Aug 13 18:22:05 2013][16261] [OC#9836] 107271.134-107273.302: OC 946088KB->860358KB (6291456KB), 2.168 s, sum of pauses 220.883 ms, longest pause 182.948 ms.
    [memory ][Tue Aug 13 18:22:07 2013][16261] [OC#9837] 107273.552-107275.500: OC 1010670KB->854399KB (6291456KB), 1.948 s, sum of pauses 120.783 ms, longest pause 56.691 ms.
    [memory ][Tue Aug 13 18:22:09 2013][16261] [OC#9838] 107275.501-107277.801: OC 906839KB->850508KB (6291456KB), 2.301 s, sum of pauses 399.919 ms, longest pause 367.834 ms.
    [memory ][Tue Aug 13 18:22:11 2013][16261] [OC#9839] 107278.052-107280.071: OC 1045319KB->862319KB (6291456KB), 2.019 s, sum of pauses 144.317 ms, longest pause 75.239 ms.
    [memory ][Tue Aug 13 18:22:14 2013][16261] [OC#9840] 107280.071-107282.578: OC 887997KB->849438KB (6291456KB), 2.507 s, sum of pauses 537.495 ms, longest pause 504.761 ms.
    [memory ][Tue Aug 13 18:22:16 2013][16261] [OC#9841] 107282.879-107284.888: OC 1061809KB->860007KB (6291456KB), 2.009 s, sum of pauses 137.893 ms, longest pause 63.667 ms.
    [memory ][Tue Aug 13 18:22:19 2013][16261] [OC#9842] 107284.888-107287.367: OC 908775KB->852632KB (6291456KB), 2.479 s, sum of pauses 541.465 ms, longest pause 504.889 ms.
    [memory ][Tue Aug 13 18:22:21 2013][16261] [OC#9843] 107287.517-107289.881: OC 1005267KB->849986KB (6291456KB), 2.364 s, sum of pauses 160.999 ms, longest pause 86.633 ms.
    [memory ][Tue Aug 13 18:22:24 2013][16261] [OC#9844] 107289.881-107292.353: OC 907985KB->848410KB (6291456KB), 2.472 s, sum of pauses 540.357 ms, longest pause 504.985 ms.
    [memory ][Tue Aug 13 18:22:26 2013][16261] [OC#9845] 107292.353-107294.314: OC 916160KB->850798KB (6291456KB), 1.961 s, sum of pauses 104.840 ms, longest pause 66.068 ms.
    [memory ][Tue Aug 13 18:22:28 2013][16261] [OC#9846] 107294.364-107296.780: OC 923551KB->849834KB (6291456KB), 2.416 s, sum of pauses 440.677 ms, longest pause 403.477 ms.
    [memory ][Tue Aug 13 18:22:30 2013][16261] [OC#9847] 107296.931-107299.111: OC 997464KB->858904KB (6291456KB), 2.180 s, sum of pauses 246.058 ms, longest pause 206.937 ms.
    [memory ][Tue Aug 13 18:22:33 2013][16261] [OC#9848] 107299.111-107301.563: OC 903415KB->851026KB (6291456KB), 2.452 s, sum of pauses 540.845 ms, longest pause 504.318 ms.
    [memory ][Tue Aug 13 18:22:35 2013][16261] [OC#9849] 107301.814-107303.861: OC 1013878KB->857614KB (6291456KB), 2.048 s, sum of pauses 94.386 ms, longest pause 53.197 ms.
    [memory ][Tue Aug 13 18:22:38 2013][16261] [OC#9850] 107303.861-107306.212: OC 887706KB->860005KB (6291456KB), 2.350 s, sum of pauses 346.029 ms, longest pause 311.092 ms.
    [memory ][Tue Aug 13 18:22:40 2013][16261] [OC#9851] 107306.262-107308.853: OC 937699KB->860853KB (6291456KB), 2.591 s, sum of pauses 557.007 ms, longest pause 501.625 ms.
    [memory ][Tue Aug 13 18:22:43 2013][16261] [OC#9852] 107308.853-107311.426: OC 951313KB->870294KB (6291456KB), 2.573 s, sum of pauses 541.352 ms, longest pause 504.381 ms.
    [memory ][Tue Aug 13 18:22:45 2013][16261] [OC#9853] 107311.426-107314.144: OC 909609KB->852710KB (6291456KB), 2.718 s, sum of pauses 583.129 ms, longest pause 504.576 ms.
    [memory ][Tue Aug 13 18:22:48 2013][16261] [OC#9854] 107314.144-107316.628: OC 969124KB->858298KB (6291456KB), 2.484 s, sum of pauses 542.151 ms, longest pause 504.257 ms.
    [memory ][Tue Aug 13 18:22:50 2013][16261] [OC#9855] 107316.628-107319.114: OC 915682KB->849121KB (6291456KB), 2.486 s, sum of pauses 495.272 ms, longest pause 447.599 ms.
    [memory ][Tue Aug 13 18:22:53 2013][16261] [OC#9856] 107319.314-107321.936: OC 1006620KB->861443KB (6291456KB), 2.621 s, sum of pauses 544.915 ms, longest pause 504.410 ms.
    [memory ][Tue Aug 13 18:22:56 2013][16261] [OC#9857] 107321.936-107324.410: OC 922270KB->852766KB (6291456KB), 2.474 s, sum of pauses 541.767 ms, longest pause 504.142 ms.
    [memory ][Tue Aug 13 18:22:58 2013][16261] [OC#9858] 107324.610-107327.023: OC 1039488KB->861496KB (6291456KB), 2.413 s, sum of pauses 542.856 ms, longest pause 504.187 ms.
    [memory ][Tue Aug 13 18:23:01 2013][16261] [OC#9859] 107327.023-107329.315: OC 918829KB->843657KB (6291456KB), 2.292 s, sum of pauses 321.525 ms, longest pause 286.826 ms.
    [memory ][Tue Aug 13 18:23:03 2013][16261] [OC#9860] 107329.616-107332.141: OC 1069773KB->863389KB (6291456KB), 2.525 s, sum of pauses 548.231 ms, longest pause 504.177 ms.
    [memory ][Tue Aug 13 18:23:06 2013][16261] [OC#9861] 107332.141-107334.343: OC 915522KB->853889KB (6291456KB), 2.202 s, sum of pauses 189.135 ms, longest pause 153.663 ms.
    [memory ][Tue Aug 13 18:23:08 2013][16261] [OC#9862] 107334.644-107337.056: OC 1032066KB->868736KB (6291456KB), 2.412 s, sum of pauses 545.438 ms, longest pause 504.254 ms.
    [memory ][Tue Aug 13 18:23:11 2013][16261] [OC#9863] 107337.056-107339.296: OC 915783KB->864080KB (6291456KB), 2.240 s, sum of pauses 298.272 ms, longest pause 263.347 ms.
    [memory ][Tue Aug 13 18:23:13 2013][16261] [OC#9864] 107339.597-107341.923: OC 1011429KB->878520KB (6291456KB), 2.326 s, sum of pauses 456.568 ms, longest pause 419.025 ms.
    [memory ][Tue Aug 13 18:23:15 2013][16261] [OC#9865] 107341.923-107343.934: OC 919359KB->840367KB (6291456KB), 2.011 s, sum of pauses 125.250 ms, longest pause 57.223 ms.
    [memory ][Tue Aug 13 18:23:18 2013][16261] [OC#9866] 107344.185-107346.733: OC 1012840KB->874965KB (6291456KB), 2.548 s, sum of pauses 540.636 ms, longest pause 504.970 ms.
    [memory ][Tue Aug 13 18:23:20 2013][16261] [OC#9867] 107346.750-107348.793: OC 933751KB->854858KB (6291456KB), 2.043 s, sum of pauses 156.099 ms, longest pause 82.344 ms.
    [memory ][Tue Aug 13 18:23:23 2013][16261] [OC#9868] 107348.793-107351.335: OC 887450KB->867195KB (6291456KB), 2.542 s, sum of pauses 537.543 ms, longest pause 504.801 ms.
    [memory ][Tue Aug 13 18:23:25 2013][16261] [OC#9869] 107351.486-107353.546: OC 996281KB->860628KB (6291456KB), 2.060 s, sum of pauses 160.157 ms, longest pause 73.442 ms.
    [memory ][Tue Aug 13 18:23:27 2013][16261] [OC#9870] 107353.546-107356.073: OC 906961KB->872330KB (6291456KB), 2.527 s, sum of pauses 539.374 ms, longest pause 504.913 ms.
    [memory ][Tue Aug 13 18:23:30 2013][16261] [OC#9871] 107356.273-107358.702: OC 996457KB->851473KB (6291456KB), 2.429 s, sum of pauses 166.761 ms, longest pause 86.493 ms.
    [memory ][Tue Aug 13 18:23:33 2013][16261] [OC#9872] 107358.703-107361.265: OC 907359KB->863117KB (6291456KB), 2.562 s, sum of pauses 541.203 ms, longest pause 504.927 ms.
    [memory ][Tue Aug 13 18:23:35 2013][16261] [OC#9873] 107361.265-107363.378: OC 912545KB->853583KB (6291456KB), 2.113 s, sum of pauses 112.867 ms, longest pause 69.906 ms.
    [memory ][Tue Aug 13 18:23:37 2013][16261] [OC#9874] 107363.379-107365.933: OC 919557KB->864998KB (6291456KB), 2.554 s, sum of pauses 543.605 ms, longest pause 504.637 ms.
    [memory ][Tue Aug 13 18:23:39 2013][16261] [OC#9875] 107365.983-107368.091: OC 958748KB->857127KB (6291456KB), 2.108 s, sum of pauses 252.535 ms, longest pause 215.897 ms.
    [memory ][Tue Aug 13 18:23:42 2013][16261] [OC#9876] 107368.342-107370.827: OC 999403KB->865783KB (6291456KB), 2.485 s, sum of pauses 540.028 ms, longest pause 504.197 ms.
    [memory ][Tue Aug 13 18:23:44 2013][16261] [OC#9877] 107370.827-107372.683: OC 923670KB->857704KB (6291456KB), 1.856 s, sum of pauses 87.595 ms, longest pause 52.619 ms.
    [memory ][Tue Aug 13 18:23:47 2013][16261] [OC#9878] 107372.883-107375.283: OC 985737KB->859804KB (6291456KB), 2.399 s, sum of pauses 487.291 ms, longest pause 451.118 ms.
    [memory ][Tue Aug 13 18:23:49 2013][16261] [OC#9879] 107375.283-107377.932: OC 915211KB->853184KB (6291456KB), 2.649 s, sum of pauses 555.557 ms, longest pause 504.480 ms.
    [memory ][Tue Aug 13 18:23:52 2013][16261] [OC#9880] 107377.932-107380.212: OC 1009969KB->874361KB (6291456KB), 2.279 s, sum of pauses 375.384 ms, longest pause 335.326 ms.
    [memory ][Tue Aug 13 18:23:54 2013][16261] [OC#9881] 107380.212-107382.461: OC 914805KB->855458KB (6291456KB), 2.249 s, sum of pauses 288.521 ms, longest pause 250.881 ms.
    [memory ][Tue Aug 13 18:23:56 2013][16261] [OC#9882] 107382.562-107384.892: OC 966755KB->867614KB (6291456KB), 2.330 s, sum of pauses 500.018 ms, longest pause 463.414 ms.
    [memory ][Tue Aug 13 18:23:59 2013][16261] [OC#9883] 107384.942-107387.565: OC 932206KB->853768KB (6291456KB), 2.622 s, sum of pauses 565.151 ms, longest pause 504.160 ms.
    [memory ][Tue Aug 13 18:24:01 2013][16261] [OC#9884] 107387.565-107389.985: OC 958792KB->862315KB (6291456KB), 2.421 s, sum of pauses 461.570 ms, longest pause 420.545 ms.

    You need to find out the error code you get in fault due to response timeout. (run a test using test console and you would get that)
    In error handler of stage from where you are calling this business service, check whether status code in $fault is equal to the error code due to response timeout. If it is equal then replace content of $body with required error xml and use reply with success.
    See section "37.6 Fault Variable" to know more about $fault -
    http://download.oracle.com/docs/cd/E14571_01/doc.1111/e15867/context.htm#i1051956
    Regards,
    Anuj

  • How to capture transaction response time in SQL

    I need to capture  Transaction response time (i.e. ping test) to calculated the peak hours and averaged
    on a daily basis.
    and
    Page refresh time that is calculated no less than every 2 hours for peak hours and averaged on a daily basis. 
    Please assist
    k

    My best guess as to what you are looking for is something like the following (C#):
    private int? Ping()
    System.Data.SqlClient.SqlConnection objConnection;
    System.Data.SqlClient.SqlCommand objCommand;
    System.Data.SqlClient.SqlParameter objParameter;
    System.Diagnostics.Stopwatch objStopWatch = new System.Diagnostics.Stopwatch();
    DateTime objStartTime, objEndTime, objServerTime;
    int intToServer, intFromServer;
    int? intResult = null;
    objConnection = new System.Data.SqlClient.SqlConnection("Data Source=myserver;Initial Catalog=master;Integrated Security=True;Connect Timeout=3;Network Library=dbmssocn;");
    using (objConnection)
    objConnection.Open();
    using (objCommand = new System.Data.SqlClient.SqlCommand())
    objCommand.Connection = objConnection;
    objCommand.CommandType = CommandType.Text;
    objCommand.CommandText = @"select @ServerTime = sysdatetime()";
    objParameter = new System.Data.SqlClient.SqlParameter("@ServerTime", SqlDbType.DateTime2, 7);
    objParameter.Direction = ParameterDirection.Output;
    objCommand.Parameters.Add(objParameter);
    objStopWatch.Start();
    objStartTime = DateTime.Now;
    objCommand.ExecuteNonQuery();
    objEndTime = DateTime.Now;
    objStopWatch.Stop();
    objServerTime = DateTime.Parse(objCommand.Parameters["@ServerTime"].Value.ToString());
    intToServer = objServerTime.Subtract(objStartTime).Milliseconds;
    intFromServer = objEndTime.Subtract(objServerTime).Milliseconds;
    intResult = (int?)objStopWatch.ElapsedMilliseconds;
    System.Diagnostics.Debug.Print(string.Format("Milliseconds from client to server {0}, milliseconds from server back to client {1}, and milliseconds round trip {2}.", intToServer, intFromServer, intResult));
    return intResult;
    Now, while the round trip measurement is fairly accurate give or take 100ms, any measurement of latency to and from SQL Server is going to be subject to the accuracy of the time synchronization of the client and server.  If the server's and client's
    time isn't synchronized precisely then you will get odd results in the variables intToServer and intFromServer.
    Since the round trip result of the test is measured entirely on the client that value isn't subject to the whims of client/server time synchronization.

  • Reporting transaction response time

    Hi all,
    does anybody knows a possibility to monitor the responsetime for a
    special transaction ( e.g. CIC0 ) ?
    Best regards
    Andreas Laaser

    Hi Andreas,
    Another way to approach this would be to use CCMS transaction monitoring by maintaining table ALTRAMONI (in the satellite system) as described here: http://help.sap.com/saphelp_nw70/helpdata/en/b3/468e3b093d4031e10000000a11402f/content.htm
    In RZ20 you'll be able to see the last 24 hours of performance data in a 1-hour granularity, as well as the last 30 minutes in a higher granularity.  Depending on your requirements you can then configure alerting so that you get an email when performance passes a certain threshold.
    Jon

  • Dramatically increased response times when connected to network

    I suddenly noticed that the response time for opening a folder item in my local Portal installation increased when I connected to the network. Why? I want to understand this, since I'm supposed to help a customer with their performance problems.
    Further details:
    The response time increased from about 2 seconds to about 10 seconds when I connected to the network. In this case, I connected via an ISDN line to my normal dial-up number at work. However, when I connect to my private ISP account (Telenor Online), the response times are unchanged, i.e. still 2 seconds.
    One difference between the two access points is the use of a proxy in the first case.
    What's the explanation?
    Thanks, Erik Hagen
    null

    Hi,
    To your issue, the following blogs would be helpful:
    Outlook Performance Troubleshooting including Office 365
    How To Troubleshoot Microsoft Exchange Server Latency or Connection
    Issues
    Thanks,
    Jessie

  • RFC response times deteriorate with time

    Hi
    We notice that every time our system is restarted, performance is much improved for a the first few weeks. I can appreciate this from the fact that it is a huge system and things can 'clog up' after a while but we have been trying to isolate any specific cause / memory leaks etc.
    One thing we have noticed is that although average dialog and background response times appear to increase gradually with time, RFC response times increase substantially. The first few days after a restart we see times of 2, 3 seconds, by the first week 7-10 seconds and by week two and beyond they are over 20 seconds.
    We have 15 application servers and all the RFC traffic is load balanced using a RZ12 group that does not include the Central Instance; the same applies in SMQR & SMQS. We still do see some RFC traffic on the CI though... some of the application servers are on a different site, but we cannot see any differences in response times across sites...
    Any ideas what's causing this and how we can keep these RFC response times down? The system is very busy and deals with a lot of RFC traffic, when users start complaining about poor performance we can usually see the system flooded with RFCs....
    Due to size and nature of this system we can only arrange a restart every couple of months.
    Thanks
    Ross

    Hi Markus, good question, but no, haven't noticed...  not sure how I'd check either? There are hundreds (if not thousands) of different transactions ran each month, I'll try sorting the transactions by time for each day and see if there are any common longer runners that have increased, but think it'll be like looking for a needle in a haystack...

  • Slow response time for JSP pages under iAS 6.0 SP4

    Hi,
    I got an application deployed on iplanet app server 6.0 SP4 on solaris
    2.8. Using a single kjs engine and lite sessions. kjs memory size is
    min 256 and max 256 megs. but verbose:gc shows memory is 98% free.
    when i restart the app server, all JSP pages are really rendered fast.
    After a while (1 or 2 days), the time to service the same request to
    JSP pages is getting much longer (even with JSP pages having only
    static content in them). CPU is idle ... It just takes time. KXS log
    shows requet is taking like 2-4 seconds instead of about 150 milli
    secs when the engine is just restarted.
    Now if i call a servlet (which do not dispath to a JSP), the response
    time is ok! Memory is ok. It looks like its related to JSP pages
    only.
    Anyone having an idea what the problem could be? One conig param is
    the JSP page cache in iASAT. Default value is 10. What is a correct
    setting for production? I have 4 different web app deployed in the
    same server instance.
    Tanks a lot for your input
    Andre Paradis

    Andre,
    I have found the answer to my problem and perhaps yours. It seems that I18N (internationalization) in SP4 may have a performance bug in it.
    My soak tests show that with i18N checked in the iAS Admin Tool, testing the fortune cookie sample application with light load (1 request / sec) resulted in a kxs response time initially of 15ms, however this response time increased by roughly 1% per request (i.e after 100 requests the response time had more than doubled).
    Switching I18N off yielded a steady 7ms kxs response time from the fortune cookie application.
    I would add that I turned I18N on AFTER the installation procedure.
    Is this a known issue in SP4? Is there a patch?
    regards,
    Owen

  • ACE max response time

    Hi all,
    I have just configured ACE 4720 and started heavy test from a single source host to the group of http servers. All works fine and mean response time during all test is good (about 0.2 sec)  but max response time  grows from about 0.4 sec. to the 3 sec. after 30 sec the test starts and sometimes up to the 6 or 9 sec. How do I fix this?

    Try to check "sh resource usage all" to see if there is "Denied" count incrementing. It could be resource issue.

  • Management Services Response Time; per Role or per Deployment? Broken?

    Management Services, Alert on Response Time, appears to be incorrect. 
    Can you help me understand why the Response Time charts for each Role in a deployment are identical? is this a bug?
    My Testing
    I have 3 Roles in my Cloud Service Deployment. A Web Role, a worker Role, and an extra Worker Role for this test.
    Web Role: Light load 0 to 10 requests per hour.
    Worker Role: Generates massive net work traffic. Constantly making web service calls to 3rd party data services & running a Distributed Azure Data Cache.
    Extra Worker Role:  No load. I added it to test this problem. It does nothing other than respond to Management Services Alert pings. 
    I created 3 Alerts to Track response time. One to each of the 3 roles, testing from within the same data center; San Jose to San Jose. Then added 3 more to test from Singapore to San Jose. 
    The Result (over several Months)
    A. The San Jose charts are identical for each role.
    B. The Singapore charts are identical for each role.
    C. The set of Singapore charts are very similar to the San Jose set of charts. With slight variations likely due to internet latency & extra load at Singapore.  
    D. (most Important). The latency is directly correlated to the network load created by the Worker Role. When I turn it off or throttle it, Response Time on all boxes drops. When working at "full speed" network response time rises
    to 10 - 30 secs. (very bad) 
    Conclusion
    The Network Monitoring Response Time Alert is not working as designed. It does not show the Response Time for that Role. But seems to be displaying the Response Time for the whole deployment. 
    My Request
    Can you assist me to understand if this is "By Design". If my testing is flawed? or what is going on. 
    My Goal
    Alert the Azure dev team to this so that maybe they can fix it to function as I expected it to. (or for them to explain why my expectations are unreasonable.) 
    Why is this important?
    Poor Network Perf is a showstopper bug that is preventing us from moving into production. I may be able to solve this with multiple instances. But as I lack the granularity to track even at the Role level. I'm stuck. 

    Thank you for your reply. 
    I forgot to update this with the answer. 
    It turned out that Azure Portal's Create Alert/monitoring UI has a bug. 
    The monitoring service is only capable of pining your public endpoints. ie: your Web Roles. Yet it lets you think you can create an Alert to monitor any of the roles within your solution. To make things worse, it shows a chart that suggests it actually is
    pinging your worker roles, when it is actually only pinging the public Web Role. 
    That is why all the Roles in your solution display identical metrics regardless of their load. Even stopping your worker roles will not affect their ping response times.  
    If your worker role fails, Azure Alerts don't tell you about it.
    NB: Using Application Insights to create alerting does not have this issue. But only because it doesn't attempt to monitor your web roles, not because it can alert you to any issues. 

  • How to find the Response time for a particular Transaction

    Hello Experts,
            Am implementing a BAdI to achieve some customer enhancement for XD01 Transaction . I need to confirm to customer that after the implementation and before implementation what is the response time of the system
    Response time BEFORE BAdI Implementation
    Response time AFTER BAdI Implementation
    Where can i get this.
    Help me in this regard
    Best Regards
    SRiNi

    Hello,
    Within STAD, enter the time range that the user was executing the transaction within as well as the user name. The time field indicates the time when the transaction would have ended. STAD adds some extra time on using your time interval. Depending on how long the transaction ran, you can set the length you want it to display. This means that if it is set to 10, STAD will display statistical records from transactions that ended within that 10 minute period.
    The selection screen also gives you a few options for display mode.
    - Show all statistic records, sorted by star
    This shows you all of the transaction steps, but they are not grouped in any way.
    -Show all records, grouped by business transaction
    This shows the transaction steps grouped by transaction ID (shown in the record as Trans. ID). The times are not cumulative. They are the times for each individual step.
    -Show Business Transaction Tots
    This shows the transaction steps grouped by transaction ID. However, instead of just listing them you can drill from the top level down. The top level will show you the overall response time, and as you drill down, you can get to the overall response time.
    Note that you also need to add the user into the selection criteria. Everything else you can leave alone in this case.
    Once you have the records displayed, you can double click them to get a detailed record. This will show you the following:
    - Breakdown of response time (wait for work process, processing time, load time, generating time, roll time, DB time, enqueue time). This makes STAD a great place to start for performance analysis as you will then know whether you will need to look at SQL, processing, or any other component of response time first.
    - Stats on the data selected within the execution
    - Memory utilization of the transaction
    - RFCs executed (including the calling time and remote execution time - very useful with performance analysis of interfaces)
    - Much more.
    As this chain of comments has previously indicated, you are best off using STAD if you want an accurate indication of response time. The ST12 (combines SE30 ABAP trace and ST05 SQL trace) trace times are less accurate that the values you get from ST12. I am not discounting the value of ST12 by any means. This is a very powerful tool to help you tune your transactions.
    I hope this information is helpful!
    Kind regards,
    Geoff Irwin
    Senior Support Consultant
    SAP Active Global Support

  • Coherence and EclipseLink - JTA Transaction Manager - slow response times

    A colleague and I are updating a transactional web service to use Coherence as an underlying L2 cache. The application has the following characteristics:
    Java 1.7
    Using Spring Framework 4.0.5
    EclipseLink 12.1.2
    TopLink grid 12.1.2
    Coherence 12.1.2
    javax.persistence 12.1.2
    The application is split, with a GAR in a WebLogic environment and the actual web service application deployed into IBM WebSphere 8.5.
    When we execute a GET from the server for a decently sized piece of data, the response time is roughly 20-25 seconds. From looking into DynaTrace, it appears that we're hitting a brick wall at the "calculateChanges" method within EclipseLink. Looking further, we appear to be having issues with the transaction manager but we're not sure what. If we have a local resource transaction manager, the response time is roughly 500 milliseconds for the exact same request. When the JTA transaction manager is involved, it's 20-25 seconds.
    Is there a recommendation on how to configure the transaction manager when incorporating Coherence into a web service application of this type?

    Hi Volker/Markus,
    Thanks a lot for the response.
    Yeah Volker, you are absolutely right. the 10-12 seconds happens when we have not used the transaction for several minutes...Looks like the transactions are moved away from the SAP buffer or something, in a very short time.
    and yes, the ABAP WP's are running in Pool 2 (*BASE) and the the JAVA server, I have set up in another memory pool of 7 GB's.
    I would say the performance of the JAVA part is much better than the ABAP part.
    Should I just remove the ABAP part of the SOLMAN from memory pool 2 and assign the JAVA/ABAP a separate huge memory pool  of say like 12-13 GB's.
    Will that likely to improve my performance??
    No, I have not deactivated RSDB_TDB in TCOLL from daily twice to weekly once on all systems on this box. It is running daily twice right now.
    Should I change it to weekly once on all the systems on this box?  How is that going to help me?? The only thinng I can think of is that it will save me some CPU utilization, as considerable CPU resources are needed for this program to run.
    But my CPU utilization is anyway only like 30 % average. Its a i570 hardware and right now running 5 CPU's.
    So you still think I should deactivate this job from daily twice to weekly once on all systems on this box??
    Markus, Did you open up any messages with SAP on this issue.?
    I remember working on the 3.2 version of soultion manager on change management and the response times very much better than this as compared to 4.0.
    Let me know guys and once again..thanks a lot for your help and valuable input.
    Abhi

  • Increase synchronous process response time

    hi all
    From my sycn BPEL process I am calling CRM sycn’ly .
    Response from CRM is coming very lately for that I am getting time out error .
    Can we achieve a scenario where my sync BPEL process will wait for a longer time .
    Its not possible to make it async delayed response also.
    Keeping it Sync only how can I increase in response time period?
    i am using SOA 10.1.3.4 version.
    thx in advance ..

    Go to the BPEL Properties in EM, then advanced BPEL properties, find the property syncMaxWaitTime And increase it to 240 may be...
    Also increase the JTA timeout in weblogic console....keep this value more than 240

  • SBWP  transaction - viewing folders/sending documents Long response times

    Hi all,
    I have some complains from some users (about 3-4 out of ~3000 user in my ECC 6.0 system) within my company about their response times on the Business Workplace. In particulat they started complaining about the response time of calling the TCOD SBWP . For 1-2 of them up to 4-5 minutes when myself as well as my other 2 colleagues were getting response of 500ms.
    Then they wanted also to view some folders on the Workplace and they had also response times of minutes instead of seconds.
    I checked that some of their shared folders as well as the Trash Bin had thousands of PDFs. I told to delete them and they deleted most of them. Stil when they want to open a folder it takes >2 minutes while for me to open the same shared folder takes 1-2 seconds.
    I checked in ST03N (user profiles, single records) and 1 of them had long database calls and request time in the Analysis of ABAP/4 database requests (Single Statistical Records).
    I am running out of ideas as I cannot explain why only for those 2-3 users happens to have long response times.
    Is it related to their folders in the Workplace? Where should I focus my investigation for the SBWP like transactions? Is it the case that some Oracle parameters might need to be checked?
    I run the automatic Oracle parameters check (O/S AIX 5.3 , Oracle 10.2 , ECC 6.0) and here are some recommandations:
    fixcontrol (5705630)                   add with value "5705630:ON"                                                                                use optimal OR concatenation; note 176754                    NO                                                          5705630:ON                                         B          1             
    fixcontrol (5765456)                   add with value "5765456:3"                                                                                no further information available                             NO                                                          5765456:3                                          B          1             
    optimpeek_user_binds                   add with value "FALSE"                                                                                avoid bind value peaking                                     NO                                                          FALSE                                              B          1             
    optimizerbetter_inlist_costing         add with value "OFF"                                                                                avoid preference of index supporting inlist                  NO                                                          OFF                                                B          1             
    optimizermjc_enabled                   add with value "FALSE"                                                                                avoid cartesean merge joins in general                       NO                                                          FALSE                                              B          1             
    sortelimination_cost_ratio             add with value "10"                                                                                use non-order-by-sorted indexes (first_rows)                 NO                                                          10                                                 B          1             
    event (10027)                            add with value "10027 trace name context forever, level 1"                                                               avoid process state dump at deadlock                         NO                                                          10027 trace name context forever, level 1          B          1             
    event (10028)                            add with value "10028 trace name context forever, level 1"                                                               do not wait while writing deadlock trace                     NO                                                          10028 trace name context forever, level 1          B          1             
    event (10091)                            add with value "10091 trace name context forever, level 1"                                                               avoid CU Enqueue during parsing                              NO                                                          10091 trace name context forever, level 1          B          1             
    event (10142)                            add with value "10142 trace name context forever, level 1"                                                               avoid Btree Bitmap Conversion plans                          NO                                                          10142 trace name context forever, level 1          B          1             
    event (10183)                            add with value "10183 trace name context forever, level 1"                                                               avoid rounding during cost calculation                       NO                                                          10183 trace name context forever, level 1          B          1             
    event (10191)                            add with value "10191 trace name context forever, level 1"                                                               avoid high CBO memory consumption                            NO                                                          10191 trace name context forever, level 1          B          1             
    event (10411)                            add with value "10411 trace name context forever, level 1"                                                               fixes int-does-not-correspond-to-number bug                  NO                                                          10411 trace name context forever, level 1          B          1             
    event (10629)                            add with value "10629 trace name context forever, level 32"                                                              influence rebuild online error handling                      NO                                                          10629 trace name context forever, level 32         B          1             
    event (10753)                            add with value "10753 trace name context forever, level 2"                                                               avoid wrong values caused by prefetch; note 1351737          NO                                                          10753 trace name context forever, level 2          B          1             
    event (10891)                            add with value "10891 trace name context forever, level 1"                                                               avoid high parsing times joining many tables                 NO                                                          10891 trace name context forever, level 1          B          1             
    event (14532)                            add with value "14532 trace name context forever, level 1"                                                               avoid massive shared pool consumption                        NO                                                          14532 trace name context forever, level 1          B          1             
    event (38068)                            add with value "38068 trace name context forever, level 100"                                                             long raw statistic; implement note 948197                    NO                                                          38068 trace name context forever, level 100        B          1             
    event (38085)                            add with value "38085 trace name context forever, level 1"                                                               consider cost adjust for index fast full scan                NO                                                          38085 trace name context forever, level 1          B          1             
    event (38087)                            add with value "38087 trace name context forever, level 1"                                                               avoid ora-600 at star transformation                         NO                                                          38087 trace name context forever, level 1          B          1             
    event (44951)                            add with value "44951 trace name context forever, level 1024"                                                            avoid HW enqueues during LOB inserts                         NO

    Hi Loukas,
    Your message is not well formatted so you are making it harder for people to read. However your problem is that you have 3-4 users of SBWP with slow runtimes when accessing folders. Correct ?
    You mentioned that there is a large number of documents in the users folders so usually these type of problems are caused by a large number of table joins on the SAPoffice tables specific to your users.
    Firstly please refer to SAP Note 988057 Reorganization - Information.
    To help with this issue you can use report RSBCS_REORG in SE38 to remove any deleted documents from the SAPoffice folders. This should speed up the access to your users documents in folders as it removes unnecessary documents from the SAPoffice tables.
    If your users do not show a significant speed up of access to their SAPoffice folders please refer to SAP Note 904711 - SAPoffice: Where are documents physically stored and verify that your statistics and indexes mentioned in this note are up to date.
    If neither of these help with the issue you can trace these users in ST12 and find out which table is cauing the longest runtime and see if there is a solution to either reduce this table or improve the access method on the DB level.
    Hope this helps
    Michael

  • Reg Increasing the EJB Response Time

    We are facing below performance problems in our application,
    1. Response time from EJB (Stateless Session Bean) to Client (Swing).
    2. Time taken for looping through the Result Set.
    For 5000 records, our query is taking 0.2 Secs but looping through the ResultSet is taking around 16 seconds and Response time for transferring 160 kb (object data) from EJB to Client is taking around 30 Secs.
    We have achieved some improvement in ResultSet looping time by setting the setFetchSize of ResultSet to 250.
    Can anyone suggest?
    1. Is there any way to increase the Data Transfer time (Response time) from EJB to Client?
    2. What is the ideal value for setting the value for ResultSet.setFetchSize() ( No of records we fetch vary from 1 � 3,00,000 records)

    1. Response time from EJB (Stateless Session Bean) to
    Client (Swing). Consider non-EJB options. They might prove efficient in your case.
    2. Time taken for looping through the Result Set. Try and design your code as to not require all the records at a time.
    For 5000 records, our query is taking 0.2 Secs but
    looping through the ResultSet is taking around 16
    seconds and Response time for transferring 160 kb
    (object data) from EJB to Client is taking around 30
    Secs.
    We have achieved some improvement in ResultSet
    looping time by setting the setFetchSize of ResultSet
    to 250. There is a limit to what you can achieve with that.
    Can anyone suggest?
    1. Is there any way to increase the Data Transfer
    time (Response time) from EJB to Client? I suppose you would want to reduce the response time.
    2. What is the ideal value for setting the value for
    ResultSet.setFetchSize() ( No of records we fetch
    vary from 1 � 3,00,000 records)
    shrug

Maybe you are looking for