Support #11323

VRE #10195: FAO Training VRE on Stock monitoring tools

FAO StockMonitoringTools for SDG 14.4.1 - Concurrency problems

Added by Enrico Anello 12 months ago. Updated 12 months ago.

Status:ClosedStart date:Mar 05, 2018
Priority:HighDue date:
Assignee:Andrea Dell'Amico% Done:

100%

Category:-
Sprint:Computational Service
Infrastructure:Development, Pre-Production, Production
Milestones:
Duration:

Description

Hi all,
FAO is making an e-learning course for the SDG 14.4.1 and there will be many links to the StockMonitoringTools shiny application embedded in the SDG 14.4.1 VRE.

The shiny applications holds a series of interactive functionalities but it seems that we can run them just one at the time; the other sessions gets in hold until the first on the chain has finished and also the ones down in the queue get a timeout after a certain while.

Is it possible to increase the number of concurrent sessions to something like 10? Do we need extra power for that like new machines? If yes how much would be the costs?

Another solution would be to translate all these methods to the data miner but we would indeed loose all the interactivity. The methods are very light weight for the datasets we will provide to the e-learning course and for this reason we embedded them in the shiny app directly rather than using the data-miner.

Can you please advise if it's possible to increase the concurrency of the Shiny Proxy for the StockMonitoringTools application or if we have to get another approach to let multiple users work on this application at the same time?


Subtasks

Support #11356: Stock Monitoring Tools not working in VREClosedAndrea Dell'Amico

History

#1 Updated by Andrea Dell'Amico 12 months ago

That behaviour was also noted when the app was deployed, but there's no limit on the concurrent instances in the shinyproxy configuration or in the docker environment. I also do not see a memory shortage.

#2 Updated by Enrico Anello 12 months ago

@andrea.dellamico@isti.cnr.it thanks,
Unfortunately I cannot test the concurrency on my dev environment because the free shiny server I am using does not allow any concurrent session by factory.
I think that the problem might be under the hoods, in particular on the R session each session relies to. Can you please check, somehow, if each session generates a different R session?

Enrico

#3 Updated by Pasquale Pagano 12 months ago

  • Assignee changed from Pasquale Pagano to Andrea Dell'Amico

@enrico.anello@fao.org, we do not recommend shinyproxy even if we can understand why you are using it. We do not recommend it because we do not have expertise on it.

@andrea.dellamico@isti.cnr.it, does it make sense to replicate the shinyproxy on 2-3 servers and proxy the requests to it?

#4 Updated by Enrico Anello 12 months ago

thanks @pasquale.pagano@isti.cnr.it
I think the only way we currently have to deploy shiny apps within BlueBridge context is the shiny proxy, isn't it?

#5 Updated by Andrea Dell'Amico 12 months ago

  • Status changed from New to In Progress

Enrico Anello wrote:

I think the only way we currently have to deploy shiny apps within BlueBridge context is the shiny proxy, isn't it?

Yes, it is.

I think that the problem might be under the hoods, in particular on the R session each session relies to. Can you please check, somehow, if each session generates a different R session?

Opening more than one app instance in different browser tabs? Which algorithms should I try? Elefan with the sample dataset?

#6 Updated by Enrico Anello 12 months ago

@andrea.dellamico@isti.cnr.it
You can try with the Elefan SA algorithm with the sample dataset you can download within the shiny app.

The sample dataset works with all the Elefan methods. Elefan GA takes a few seconds to complete, Elefan SA around a minute while Elefan around 5 minutes.

Cheers,
Enrico

#7 Updated by Andrea Dell'Amico 12 months ago

In the meantime I run the Elefan algorithm. From what I saw in the docker logs, the computation starts immediately on every instance (I started the second three minutes after the first, the calculation on the second finished two minutes after the first). I'm going to run more parallel sessions.

#8 Updated by Andrea Dell'Amico 12 months ago

  • % Done changed from 0 to 50

I've found the problem. The server has 4 CPUs, so at most 4 containers are spawned. All the requests after the fourth are queued. So it's a matter of adding more vCPU to the VM and restart it.

Tell me when it can be done.

#9 Updated by Enrico Anello 12 months ago

@andrea.dellamico@isti.cnr.it great! You can do it even now!
How many CPUs can be added to the instance?

#10 Updated by Andrea Dell'Amico 12 months ago

I can rise them to 12. Is it enough?

#11 Updated by Enrico Anello 12 months ago

should be good for the time being. In the future there might be the need to increase them to 24.

#12 Updated by Andrea Dell'Amico 12 months ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Feedback

We are not able to provide that many resources on a single host, we will have to split the service on more than one VM. That should be completely transparent to the end users, but we'll need some days to build the configuration.

The server is running with 12 CPUs, in the meantime.

#13 Updated by Enrico Anello 12 months ago

No problem if you need some days for the configuration. The important thing is that we can add more CPUs if needed :)

Thanks @andrea.dellamico@isti.cnr.it

#14 Updated by Andrea Dell'Amico 12 months ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF