Multi-threading solution(s) to process intensive problem

Multi-threading solution(s) to process intensive problem

  
Hello everyone,

I am new to OutSystem and I am looking for an elegant solution to my particular problem.
I am running an OutSystems Process that executes a SQL-heavy statement that calculates and fetches a pricing table for a particular customer. My current solution is acceptable for a single customer use but leaves much to be desired when running for multiple customers.

Here are a couple of solutions that came to mind:

- Write my own extension which splits each unique Process to a single thread.
- Use a Timer to run and execute asynchronous tasks

My questions are: Can I pass a Process as a parameter to be used in a thread? Or do I need something more specific?

How do I schedule a Timer to run upon request?

Feel free to share your ideas and input.

Kind regards,

Ricardo
Hello Ricardo,

Without having more detailed context, I would say that you can tackle this problem using 2 concurrent approaches:


1) First and foremost, optimize the heavy statement. Surely there must be a way to reduce the load and the time it takes to calculate those values. Either optimizing the query, or add additional entities and attributes to hold pre-calculated values (like cubes and data set aggregation).

2) Second, if you really have the need to run multiple concurrent threads for the same calculations, timers won't be able to help up, as the same timer can only run once instance at a time. But you can do this with BPT Processes, if the time it takes to run the calculations is less then 5 minutes. BPT Processes instances can run in parallel, up to 5 per front-end server by default. Although this might help you for a short number of concurrent requests, it will not scale for a larger number of customers, unless the logic that takes too long runs asynchrounsly using web services, and the BPT Processes triggers the calculation launch and pools for the calculation ending, all using web services (SOAP or REST), which will also solve the problem of the 5 minutes execution time.

Again, this is from the top of my head without a depper analysis of the requirements you're facing.

Hope this helps.

Cheers
Hello Miguel,

Thanks for your elaborated response. With regards to your suggestions:

1) There are some optimisations to be had but they are minor. I forgot to mention that I already fetch 'relevant' data for customers when launching the app. 

2) I really wanted to atempt a threaded approach, but I manage to get the desired performance by using BPT processes. The concrete solution was running a Process that scheduled and fired of my calculation query. 

I do feel that this would have been a great excercise, but I am happy with the result.

Thanks again for your input Miguel.

Kind regards,

Ricardo

Miguel João wrote:

up to 5 per front-end server by default. 

Hey guys,


where can I change this setting?

Thanks a lot for your help.


Best regards,

Ricardo Saraiva wrote:

Miguel João wrote:

up to 5 per front-end server by default. 

Hey guys,


where can I change this setting?

Thanks a lot for your help.


Best regards,


It is 10 per server, and it is deliberately not documented or supported to change it (last I checked).

J.Ja

Justin James wrote:

It is 10 per server, and it is deliberately not documented or supported to change it (last I checked).

J.Ja

Hey Justin,

where do you found in the (evil) documentation that are 10 instances per frontend server?

Can you share the link?

Thanks a lot.


Ricardo Saraiva wrote:

Justin James wrote:

It is 10 per server, and it is deliberately not documented or supported to change it (last I checked).

J.Ja

Hey Justin,

where do you found in the (evil) documentation that are 10 instances per frontend server?

Can you share the link?

Thanks a lot.


That information (as well as how to change it) came through a support ticket we filed. Because it is super not-supported, I'm hesitant to share further details.

That said, the BPT architecture does not do well with real-time, high-volume processing, it's queue model delays the start of each activity by up to 50 - 100 ms... in a Process with a ton of Activities, this can add 5 - 10 seconds to the processing all by itself.

J.Ja


Justin James wrote:

That information (as well as how to change it) came through a support ticket we filed. Because it is super not-supported, I'm hesitant to share further details.

That said, the BPT architecture does not do well with real-time, high-volume processing, it's queue model delays the start of each activity by up to 50 - 100 ms... in a Process with a ton of Activities, this can add 5 - 10 seconds to the processing all by itself.

Justin,


thanks again for the information.

Anyway, I already know the right entries in OSSYS_PARAMETER table.

...but for the same reasons you said, I'll also not share it here.


Again, thanks for your help.


Best regards,

--

R. Saraiva