We have a public-facing service that utilizes Rhino.Compute. It is installed on AWS and runs under IIS using the latest recommended Deployment scripts.
On the most powerful AWS machine (for Rhino use) we are seeing a 30-second delay while the compute.geometry processes fire up after timing out. That’s probably unacceptable in our scenario.
My question is: Is there a way to keep the processes alive forever?
I have been able to hack this by using the AWS Health Check service to send a get request with the “/” path (/version also works). (At least I think it works – I can see that those two paths cause the processes to fire up after an IIS restart, but I haven’t yet tried letting that run for a long time.)
However, AWS health checks come every few seconds; way more than necessary for this goal, and it really junks up the log files.
Another possible approach:
I see that IIS would keep rhino.compute.exe running forever if I set the Idle Time-out to 0.
I could also set spawn-on-startup in web.config
Could I set the idlespan to 0 in web.config to keep the processes alive?
Hi Bill. Yes, I was leaning towards a similar approach as to one of your suggestions. I would recommend setting the --idlespan parameter in the web.config file to something very large. You can read more about how to set that here. I don’t think you want to change the --spawn-on-startup value though as that is typically set to true when you’re running rhino.compute locally but not when running on a VM. I think you really only need to change the --idlespan to a very large number to make things work. You may also want to change the IIS idle timeout value as well. The --idlespan value that you set in the webconfig is what tells rhino.compute.exe how long to wait before closing the child process (compute.geometry.exe). However, IIS also has a timeout value where it will shut down rhino.compute.exe if it doesn’t receive any incoming requests within a certain time frame. And when you shut down rhino.compute.exe, it also shuts down the children too. So, I would also recommend changing the IIS timeout value in the IIS Manager. You can read how to do that here.
Lastly, I just wanted to mention that the /healthcheck endpoint doesn’t actually launch any child processes. This was by design so that you could test if rhino.compute was running but you didn’t want to start getting billed by core-hour-billing. If you want to actually start the children you can use the /activechildren endpoint which will return an integer value stating how many child processes are running. It will likely be 0 the first time, but that request will cause rhino.compute.exe to start up the default number of compute.geometry.exe processes so if you ping it again after you’ve allowed some startup time, that number should go up. You can also just send it a valid request to the /io or /grasshopper endpoints and that will also start the children processes too. Just FYI.
You can also use Kestrel.
In our case, it works pretty well. I’ve hardly used IIS in production and can’t say much about its speed, but a 30 sec delay sounds daunting. Kestrel will seem easier if you are used to unix.
I just made a request while I was writing a comment. (I know for a fact that the machine has been idle for more than 48 hours) We use idlespan by default, kestrel and reshaper backend to run and schedule.
P.S.
If you have a really high cloud workloads, you’re going to have to resort to External Balancing and VM-level replication anyway, whatever IIS promises you.
The parent rhino.compute layer uses a Kestrel server. And you are correct that there’s a bit of redundancy in placing the reverse proxy Kestrel server of rhino.compute behind another layer of IIS. However, IIS does handle spinning up rhino.compute and keeping things alive if rhino.compute somehow crashes which is one benefit. But there are many ways to deploy rhino.compute and we ultimately thought that using IIS would be the best way… but we’re also leaning through this process
