I have deployed Rhino compute on my EC2 instance. I receive multiple concurrent web requests to run compute. What is the multi-threading behavior by compute. If I increase the childcount to a high number, the system becomes very slow. Aren’t the child processes spawned based on the number of requests? Since it is a web application, the traffic is even. I want compute to spawn the child processes based on the incoming requests.
The current behavior is that rhino.compute launches all of the child processes (based on the web.config file) whenever it gets its first authenticated request. These children will stay active until the idle timeout value is met, I don’t think we have a method for selectively spawning additional children via requests. I’m also not sure that would give you the desired outcome. I realize that spawning a lot of children can be slow but once they’re loaded, the response time should be relatively quick. I think if you waited to launch children later when multiple requests are received, the response times would be slower because it’s still spawning a few children (which takes time). Is it possible to hit the /activechildren endpoint (which is one method which starts the spawning process) before you expect your first valid request?
1 Like
Hi Andy and Aditi,
I have a similar question regarding the child count. If I send the requests to rhino.compute one at a time so that I wait for the response of the first request before I create the next, will a higher child count increase the performance of the computation (given that the machine I’m running it on has the adequate specs).
Right now I’m running compute on a VM with a 64gb vRAM and 16 cores I believe, and I’m using a child count of 8. All the compute.geometry processes only takes up about 10% of memory and CPU at its peak and I’m wondering how I can get more bang for the buck. Should I:
- Keep sending the requests 1 by 1 and increase the child count or
- throwing multiple requests at the machine at once (they’re stored in a queue and are being processed sequentially)?
Thank you so much!
Best,
Erik
If you’re sending requests 1 at a time and waiting for a response before sending another one, then there’s no sense in spawning multiple children as only one will ever be used. However, you could see better performance by spinning up multiple children and then sending multiple requests in rapid succession. This will allow the rhino.compute.exe parent layer to determine which child process gets which request… but theoretically you should see significant performance increase by having multiple worker threads (ie. the children) working on your requests and speeding up the time it takes to get the response. Does that help?
Hello Andy,
thanks for you quick response. Yes that is really helpful! Is there a good rule of thumb for the ideal child process count for a specific number of cores on the VM? If I have 8 cores, is 8 a good number for the child count parameter as well then or should it be kept a bit lower would you say?
Thanks again!
Best,
Erik
No, there’s no great “rule-of-thumb” here because the number of children is highly dependent on each project’s use case. Some times, it could be beneficial to only use one or two children if you don’t think you’ll ever be sending many concurrent requests. Using less children means that lag time upon startup (when you send your first request) will be shorter. However, other use cases would benefit from having as many children instances working as possible. So, it’s entirely up to the user to determine their own requirements. I hope that helps.
1 Like