Best way to fire up rhino compute on Azure


I’ve installed rhino compute on an Azure server via IIS. It works fine, but as described here for AWS, it takes like 30s to “warm up” on the first connection after a long time. It works smoothly afterwards.

I would like to know as of today what’s the best way to deal with that. I thought of launching a “virtual connection” in the background but it doesn’t seem very “clean” and forces to always have one active child even though there’s no proper computation.

To be clearer, is there a way to keep the server running without Rhino itself (and without the core facturation associated)?

Thanks in advance for your feedbacks!

1 Like

You can change the idlespan value which tells the Rhino.Compute process when to shut down the child processes (ie. Compute.Geometry). The default idlespan value is set to 1 hour, so if Rhino.Compute doesn’t receive any valid requests for 1 hour, then it will shut down all of the children… and then when you send it a new valid request, it will start them back up… but the startup process is what takes the most time. Follow this section of the guide in order to modify the idlespan value to something larger. I should note that you only get billed (by McNeel) when the children Compute.Geometry process is running. So, if you’re planning on keeping this process alive longer, it will mean that you will be billed more by us. I just wanted to let you know that in case you were unaware of that. I hope this helps.

Hi Andy, thanks for your answer.
Just to be sure: there really is no way to reduce the idlespan but keep the server “alive” with no children? I understand the concept but to have a good latency it forces to always have a child running, thus a 72$ (30days x 24hrs x .1$) fixed cost by month?
It seems that paying for a proper compute, and avoiding having a 1min lag at every launch could be two separate things?
Thanks in advance

Unfortunately, no. There is no way to do this. We actually separated the two projects (ie. Rhino.Compute and Compute.Geometry) so that Compute.Geometry could be shut down (so that you don’t get billed) but still have the Rhino.Compute process still alive and listening for incoming requests. But the only two “solutions” that are available is you can either preemptively send a request to the server (prior to an actual user request) and tell it to start spinning up the children. The best way to do this is to send a GET request to the /activechildren endpoint. This will tell Rhino.Compute to start spinning up the children processes. Or, alternatively, you can change the idlespan value and leave the Compute.Geometry process running so that you don’t have to wait for the startup time. You can try to minimize the startup time by removing any unused 3rd party plugins (as these are loaded for each instances that gets spun up) or by lowering the number of children processes that have to get started. I’m afraid that’s all that is available at the moment.