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

Similar Messages

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?

OSB - Service Invocation instance response times

Hi,
In my research and discussion with OSB vendor team, I found there is no product feature to gather statistics on per invocation response times for a OSB service.
My requirement is to gather per invocation response time of service. I am contemplating few ways of doing this
1. Java call outs before the start and end of service.
Downside of this approach is in my composite service (composing 10 biz services) with challenging response time requirements, it might be a over head to wrap each biz service with java call outs for measurements. Any thots?
2. There is a report feature in OSB. How about using SNMP traps for reporting the start and ends. I am wondering if this is any better than java call outs which might be synchronous I/O operation.
Do you folks see alternate approaches?
TIA

I think that generally it's not a good idea to modify production logic (code or configuration) to gather any statistics. It may look simple, but there is still possibility of unexpected failure that would cause failure of your service. Not to mention complexity of such a step.*
I totally agree.
This kind of data should be gathered from your infrastructure components. I know that OSB doesn't provide such a feature, but if you have your services published on HTTP protocol, than you can always use some kind of proxy server. In our company, we use feature-rich Apache HTTP server for many reasons. Response time logging is one of such reasons.*
Interesting. Thanks. This approach might help gather stats on the Proxy services. However the biz services composed inside proxy may not get the stats.
Another possibility is to use a specialized component. I think that OWSM can be useful. However, I don't have any experience with it and it could be overkill considering your needs. http://www.oracle.com/technology/products/webservices_manager/index.html*
We are looking into OWSM, as you rightly said, wanted to keep it simple without OWSM.
Thanks

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

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

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...

How to increase built-in cisco vpn peer response timer?

Hi,
I use OS x in-built cisco vpn client to connect to work VPN.
The VPN server, or perhaps the radius server, takes a long time to return a response. OS X always try for 10 seconds, then drop the conneciton when no response from the remote peer. When I use cisco vpn client on a windows machine, the vpn client has a setting to allow for 90 seconds remote peer response time. It works fine using cisco vpn client.
I prefer to use os x as my primary working environment, so I need to fix this problme. My question is how to increase the phase 1 & 2 timer for vpn under 10.6.7. I have tried to change racoon.conf phase 1 & phase 2 timer, but it made no difference. OS X only try for 10 seconds.
Any ideas? (besides asking work people to fix the server or radius problem)
Thanks
jmsherry123

i have the same problem ... certificate is imported in keychain, but cant select it when setup vpn connection

OSB Service Response times

Hi,
How do we monitor the response time measurement of each service invocation? I am aware that OSB provides Service Health by which Avg Response times can be monitored.
However I am looking for any OSB native capability that will provide start time, end time, response time for each instance of service invocation. Is there a way to do this in OSB in a native way without custom logging start time, end time in the service message flow itself?
Thanks

I think that what you need is a sort of access logging functionality. This feature is provided out of the box by WebLogic Server:
http://edocs.bea.com/wls/docs103/config_wls/web_server.html#wp1059425
Above all, look at extended log format. I guess you will find it useful.
If you won't be happy with this feature, you can still think about using a web server (or anything else that can log for you) as a proxy in front of OSB. That's what I prefer personally. For example using Apache HTTP Server (with WebLogic plugin) will provide you with capabilities to log anything you want.

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

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

How can increase response time:dialog

Dear all,
how can i change(increase/decrease) dialog workprocess response time?

> how can i change(increase/decrease) dialog workprocess response time?
Can you please tell us exactly what you want to do?
Read
http://help.sap.com/saphelp_nw04/helpdata/en/21/2c8f38c7215428e10000009b38f8cf/frameset.htm
about what "Response time" is defined and then please rephrase your question.
Markus

HP Pavilion hard drive response time is very slow but tests pass (evenutally)

I have owned a HP Pavilion M1199a originally running Windows XP, but has been running Windows Vista 32-bit for the last 3 years or more.
The PC started to lock up for 30 seconds or more (2 weeks ago), with the disk light constantly on then go again for no apparent reason. These lock ups have become more frequent and for longer durations. I removed anti-virus software, and a few other applications/services but generally this computer is fairly clean as I use it as a media center PC.
I have tried checking the disk (SATA) for errors, and it passes although the tests take a lot longer than they should. The resource monitor shows no excess CPU usage and there is plenty of memory available. The disk monitor shows response times of 5000-20000 ms.
What is the best way to proceed from here? Is there a SATA controller or motherboard (ASUS PTGD1-LA) test? Should I buy another SATA drive and try that? I suspect that it is either the drive, drive controller and/or the motherboard that is failing but I don't know how to isolate the problem. The computer hardware configuration has remained the same for years.
The OS has the automatic updates enabled and I uninstalled the recent ones in case they were somehow causing an issue.

tr3v wrote:
Thanks for replying.
1/ No, but I am running Vista, so assume this will be the same? Or should I just look at the tmp and temp environment variables to see what folders are being used?
In Vista type temp in the Search programs and files box and double click on the temp files icon that appears above. Delete all the files in the folder that you can. It is safe as they are exactly what they are called and that is temporary files. If you haven't done this ever or in quite a while there should be a noticeable increase in the operating system's response time.
2/ Yes. It completes after a very long time.
5/ No - but will try this out too.
****Please click on Accept As Solution if a suggestion solves your problem. It helps others facing the same problem to find a solution easily****
2015 Microsoft MVP - Windows Experience Consumer

SAP GoLive : File System Response Times and Online Redologs design

Hello,
A SAP Going Live Verification session has just been performed on our SAP Production environnement.
SAP ECC6
Oracle 10.2.0.2
Solaris 10
As usual, we received database configuration instructions, but I'm a little bit skeptical about two of them :
1/
We have been told that our file system read response times "do not meet the standard requirements"
The following datafile has ben considered having a too high average read time per block.
File name -Blocks read - Avg. read time (ms) -Total read time per datafile (ms)
/oracle/PMA/sapdata5/sr3700_10/sr3700.data10 67534 23 1553282
I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
2/
We have been asked to increase the size of the online redo logs which are already quite large (54Mb).
Actually we have BW loading that generates "Chekpoint not comlete" message every night.
I've read in sap note 79341 that :
"The disadvantage of big redo log files is the lower checkpoint frequency and the longer time Oracle needs for an instance recovery."
Frankly, I have problems undertanding this sentence.
Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right ?
But how is it that frequent chekpoints should decrease the time necessary for recovery ?
Thank you.
Any useful help would be appreciated.

Hello
>> I'm surprised that an average read time of 23ms is considered a high value. What are exactly those "standard requirements" ?
The recommended ("standard") values are published at the end of sapnote #322896.
23 ms seems really a little bit high to me - for example we have round about 4 to 6 ms on our productive system (with SAN storage).
>> Frequent checkpoints means more redo log file switches, means more archive redo log files generated. right?
Correct.
>> But how is it that frequent chekpoints should decrease the time necessary for recovery ?
A checkpoint is occured on every logswitch (of the online redologfiles). On a checkpoint event the following 3 things are happening in an oracle database:
Every dirty block in the buffer cache is written down to the datafiles
The latest SCN is written (updated) into the datafile header
The latest SCN is also written to the controlfiles
If your redologfiles are larger ... checkpoints are not happening so often and in this case the dirty buffers are not written down to the datafiles (in the case of no free space in the buffer cache is needed). So if your instance crashes you need to apply more redologs to the datafiles to be in a consistent state (roll forward). If you have smaller redologfiles more log switches are occured and so the SCNs in the data file headers (and the corresponding data) are closer to the newest SCN -> ergo the recovery is faster.
But this concept does not really fit the reality because of oracle implements some algorithm to reduce the workload for the DBWR in the case of a checkpoint.
There are also several parameters (depends on the oracle version) which control that a required recovery time is kept. (for example FAST_START_MTTR_TARGET)
Regards
Stefan

Average HTTP response time going up week by week as said by SAP

Hello All,
I was looking into our SRM earlywatch report,SRM is on windows SQL server 2005 with Windows 2003 server
In the performance indicators,there is an interseting trend though nothing is in yellow or red
The values of following parameters : average response time in HTTP task, the maximum no of HTTP steps per hour and the average DB request time in HTTP task are going up
I understand that as the no of HTTP steps are increasing,the response time is becoming more which is quite obvious.
But how to balance this load out so that the average response time comes down?
what steps should be taken so that I can get this response time to come down though the load on the server is going up
Rohit

Hi Rohit,
Is you system in High Avalibity setup? If yes, then try to load the balance on Node A and Node B. If this is already done or if your system is not in high availability then plan and install a Additional application server (Dialog instance) for load sharing.
Regards,
Sharath

Why is Oracle Response time getting slow with time.

Hi,
     I have DB which was very fast initially with the response time for one of the query < 5 sec.
     I have been using the DB for the last 15 days. Now the same query is taking 10 minutes. In the DB there are lot of operations of additions and deletions been done on the table where the query is being made. The no. of records in the table is constant at around 3 million records from the first day.
     If I import the DB into a new setup then again the response time becomes very good in the new setup.
     What should be the problem of the DB getting slow with the time.
Thanks,
Tuhin

It all depends on several factors.
Are your tables,indexes have upto-date statistics?
I have DB which was very fast initially with the response time for one of the query < 5 sec. Initially there might be small amount of data later data might have increased,you dont have proper indexes.
It could be that your indexes got fragmented to due to heavey deletes? It might need reorg.
My suggestion would to look into your execution plan of the quries and see where your kernals are waiting.
As other suggested you, use explain plan, event 10046 and tkprof.
Jaffar

Response time increase in OSB

Similar Messages

Maybe you are looking for