Sample scenarios

You can use the typical discovery sensor rates to help determine how many discovery servers that you need to meet your discovery requirements.

Increase the thread count value, dwcount, until you get memory, processor usage, or both, constrained on your discovery server. Then, scale your discovery servers as appropriate.
Estimating the number of discovery servers that are required is difficult for the following reasons:
  • It is not always known in advance how many sensors will run on each server.
  • The time taken for a sensor to complete can vary widely based on the configuration of the target server.
When monitoring discovery through the UI, consider the following general rules:
  • If the number of sensors that are running is much greater than the dwcount value, TADDM is waiting to store data. TADDM waiting to store data is an indication that you might need to increase the capacity of your storage servers, that is, add another secondary storage server.
  • If the number of sensors running is about the same as the dwcount value, TADDM is waiting for sensors to run. TADDM waiting for sensors to run is an indication that you might need to increase the capacity of your discovery servers, that is, add another discovery server, increase the dwcount value, and so on.

When using a streaming server deployment, you can easily add or remove secondary storage servers, discovery servers, or both, as your needs change or your environment grows.

Sizing example

The discovery storage rates are theoretical maximum rates. While the maximum rate might be reached for some time during a long discovery, in most cases the storage rate is less. For this scenario, a 50% rate is assumed.

The number of SEs to be discovered is 60,000 and there is a requirement for the discovery to complete within five days.

Using one storage server, it would take 9.6 days to discover and store the results of 60,000 SEs, not meeting the requirement. The following table displays the calculations for the example using one storage server.
Table 1. Example using one storage server
  CIs SEs Time (days)
Week 43,545,600 43,545.6  
Day 6,220,800 6,220.8 9.645061728
Hour 259,200 259.2  
Minute 4,320 4.32  
Second 72 0.072  
Using one primary storage server and two secondary servers, it would take 4.96 days to discover and store the results of 60,000 SEs, meeting the requirement. The following table displays the calculations for the example using two storage servers.
Table 2. Example using two storage servers
  CIs SEs Time (days)
Week 84,672,000 84,672  
Day 12,096,000 12,096 4.96031746
Hour 504,000 504  
Minute 8,400 8.4  
Second 140 0.14  
Using the discovery sensor rates from the previous example, the following table shows the number or discovery servers that are required for sensor processing to meet the one day requirement.
Table 3. Example for discovery servers
Number of servers Average sensor time per server (in minutes) dwcount Total sensor elapsed time (in minutes) Total sensor elapsed time (in hours) Number of discovery servers needed per hour
60,000 30 32 56,250 938 39.06
60,000 30 64 28,125 469 19.53
60,000 30 96 18,750 313 13.02
The total sensor elapsed time is calculated in the following way: (Number of servers/dwcount) x average sensor time per server

This example is for illustrative purposes and assumes Level 3 discovery. The actual number of discovery servers can vary based on the actual average time per sensor.