Can anyone tell me how many robots a Hub should be able to handle? I also would like to know how many hosts can be added to the net connect probe and how many profiles can be created in a url response probe.
We've tested with up to approx 5000 robots on a single hub. I personally have tested the url_response probe with up to 5000 URLs, and it worked well on a linux platform, but not so much on a windows. Net_connect should be something similar, but I've heard that it can theoretically max out at 10,000 devices/min. Hope that helps.
we run url_response on windows side and I've had approxiamtly 250 profiles but I wouldn't push it much further than that. I would reccommend linux as sachinsharma stated. It can be a bit much in windows and I believe windows is subject to connection limitations that *NIX systems don't have or are at least much higher limit on *NIX.
Also, a lot of it depends on your systems resources as well as your frequencies with remote probes. Those probes should have at least a max_threads setting in raw config and possible a min_threads which allows you to set how many threads for the runs on the profiles. More threads the more reasources but allows you to get through all the profiles if you have high frequencies. I would start with leaving the defaults and just keep an eye on the logs to make sure it is getting through the profiles.
Thanks, I have some Windows hubs with over 600 robots and recently I started to notice when attempting to open up some of the probes on some robots I would receive communication errors. After a couple of attemps it would clear.
I also started to notice some url response alerts with "no thread available" in the message. I was told this is due to too many profiles? All of the response probes I have are at about 100 or less. Any ideas?
I found this from a ticket in our system:
The url_response will at startup allocate memory for and start the configured number of minimum threads. Then it will try to execute all the active profiles. If the number of active profiles are higher than the number of available threads you will get the "No threads available" message. After the third attempt to execute a profile and no thread is available for this one (1) new thread will be started unless this exceeds the configured number of maximum threads. The profiles that are not executed because there are no threads available for them will be delayed for 20 seconds and then another attempt to execute them will be made. The probe is by default configured to limit the number of concurrent profiles to 100. This means that more profiles can be defined, but then the profiles will be checked after each other so that this can potentially lead to profiles not being executed at the exact scheduled time. An alarm will be issued on this situation. The limit can be modified with the 'max_threads' setting in the configuration file. Be aware that you will need to check the resource usage of the probe when doing so to make sure not to run into machine-dependant limitations for memory, threads or connections. The probe initially allocates 'min_threads' for profile execution. If there are more profiles defined than this, the probe may gradually increase the number of threads. As I mentioned, profiles that not immediately executed are allocated a thread are rescheduled 20 seconds later. You can configure the min_threads and max_threads options via Raw Configuration for the probe by selecting the probe and holding down the SHIFT key, Rt-Click and select Raw Configure... Here is some benchmark information from R&D for url_response v3.63 or higher - we were able to run the url_response probe v3.63 with 370 active profiles on a Windows XP physical machine (CPU: 2 GHz, RAM: 1 GB). We have not observed delayed alarms for profiles with the following probe configuration: min_threads: 100 max_threads: 500
check 'interval': set to '300' seconds for all profiles
Thanks for this information. Our hubs are Windows 2003 32 bit, 2.6 GHz CPU and 2GB RAM. I just looked at the Raw Configuration for the url_response version 3.71 and see that min_threads is set to 10 and max_threads set to 100.
If I have 80 profiles, should I set the min_threads to 80 and leave the max_threads at 100? Just want to make sure I understand this, the min_threads is the number of profiles that are checked at one time?
Yes, I'd set that minimum to a higher number. 80 should be good so all the threads can be checked all at once. You should do some testing to see if 40 at a time helps the box perform better and if you still see the threads alarm from url_response. This should help out tremendously!
Retrieving data ...