E9.2 Orchestrator Performance Improvement

[Ashwin Ramkumar]

Hi,

I've Created an Orchestration which has three form request and Two rules and two custom groovy script and an Message request. The Process time it takes is almost 20 seconds.

Can someone please tell on how to improve the performance to process this under 8 seconds or less.

Also generally what would be the steps or process to make the orchestration faster ?

 

[DaveWagoner]

In my experience the Form Requests are big potential spots for bad performance.

If you are working with forms/programs that are sitting on top of lots of records, I see performance degrade across multiple calls, the more records I add. So if I'm not needing to pull more than 1 grid record in a given form request, I set the max # of grid records returned to 1. This consistently speeds up my orchestrations, especially when I'm calling an orch via ADEX hundreds or thousands of times in a data conversion.

I literally did this very thing today as one of my orchs was getting slower and slower. Cleaned the performance right up. There's a oracle support article out there about this, which is how I found it.

Within a form request,
1) Click Form Request Options
2) Set Maximum Records to 1
3) Click Save

 

[DaveWagoner]

You could use debug mode on your orch to run through step-by-step to see which step(s) spend time processing. It should show up in debug mode the same as it might be showing up in your other testing.

 

[kaliraj]

Try Turning on Turbo mode to HIGH and check if it helps in reducing processing time.

 

[Ashwin Ramkumar]

That Helped , but there is another Orchestration which I created for CAMS Work Order Creation and Update (P13700). It has only a Form Request and a Custom groovy. While running this in debug mode I found the FREQ takes almost 4 secs to process. The Process that I'm doing there is just updating the Status. All the Orchestration which is related to these applications gets affected by the performance ( P13700 , P13714).

Is there any way to find out what's causing these slowness ?

 

[kaliraj]

How much time does it take if you create the same in E1. The Orchestration should also take the same timing.
Play around the options marked in yellow and see if increase the performance.

 

[DaveWagoner]

The first run of a form in a given time period (let's say a day) causes a "JITI" where everything gets loaded. When I call an orch with FR's 100 times rapidly, the first time in a given session takes probably 5-10x longer than the subsequent runs. So that's one consideration. Run it once, and then run it again soon after to see if the performance gets 5-10x better on run #2.

Next you can tune your form request like I and kaliraj mentioned.

Also, you can MANUALLY run your transaction through the forms to see if it's that slow from the frontend ui. There might be some logic on the form that loops through lots of data, etc.

Finally you can look for software updates that might fix bugs related to performance related to that application.

These are my opinions based on my experience, someone here has more and better experience

 

[Ashwin Ramkumar]

Thanks Dave.

The time it took to open P13700 was almost 8 secs in Web E1. So I guess the slowness is there in the application itself. Without improving the performance there, I dont think the orch can perform any faster.

 

[Gustavo Barizon]

Hi,

I've Created an Orchestration which has three form request and Two rules and two custom groovy script and an Message request. The Process time it takes is almost 20 seconds.

Can someone please tell on how to improve the performance to process this under 8 seconds or less.

Also generally what would be the steps or process to make the orchestration faster ?

View attachment 19728

Use Logic Extensions instead.

 

[JohnDanter2]

Great advice here, but also what are your SREQ form recordings actually doing?
If they are only being used to GET data and not amend it in anyway, I'd change them to data requests to do the same thing

If they are amending data, try and get the BSFNs that are being used in the SQL to insert otr update and mimik what it is doing in your debug log in a SREQ but for a BSFN call. Way faster