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)?
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.
Thanks for your reply. I don’t fully understand though i’m afraid.
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.
This is actually exactly what i would like to do! Do i understand correctly that if i regularly spawn /activechildren requests the Rhino.Compute will be kept alive, enabling better reactivity, but the different Compute.Geometry won’t? I mean, if all the children processes already have been killed, they won’t be able to “be kept alive”. Doing so would enable me to reduce the latency at initiation without being billed wouldn’t it (even though i understand it is a bit “manual”)?
Also, is every “hour of compute started due” or can i reduce the idlespan if i consider my users won’t spend more than 15min on every model?
Thanks in advance, sorry for this additional request for precision but it’s an important topic on our side.
Ok. Let me see if I can explain the architecture of how Rhino.Compute (as a web server) is setup. Rhino.Compute is made up of two Visual Studio projects. The first (which we’ll call the parent process) is called Rhino.Compute. The second (which we can call the child process) is called Compute.Geometry.
When the web server is started, it launches the parent process whose primary job is simply to listen for incoming HTTP requests. If it receives a request, it first tries to validate the request using the API key in the header. If the request is valid, then it checks to see if any child processes are running. If none are running, it will begin the process of starting one or more of the child processes.
The children are the ones who are doing the actual geometry calculations. They’re the main workhorses here. And whenever one of these processes get started, that’s when you begin getting billed according to the core-hour billing procedure. We do not care how many children you spin up. The core-hour billing procedure doesn’t even look at the number of children that are running. Instead it looks at the number of cores that your VM uses. This is all explained in the documents.
If, after some time has passed (default to 1 hour), and your server hasn’t received any new valid requests, the parent process will start turning the child processes off. This was added so that you aren’t getting billed by us 24 hours a day. Originally, the web server only had the Compute.Geometry project (with no parent process) which meant that you would get billed by us the entire time until you shut it down yourself. Now, the parent process does that for you. And, yes, you can modify the idlespan value to whatever you want it to be (see the guides).
Does this all make sense? Do you have any follow up questions?