SNAMP Performance Tips

This page contains information about SNAMP performance tuning.

Memory calculation

The minimum amount of memory required for single SNAMP process is 512 MB. This amount of memory is enough for launching single gateway and one or two resource connectors.

RAM calculation methodology reflects SNAMP requirements only. So, the total RAM space installed in your hardware must be greater than space required by SNAMP because OS and other daemon processes utilize its own memory. Pay your attention: SNAMP should not swap its memory.

If you have a plan to use up to 10 resource connectors then allocate 1 GB per SNAMP process. Tens of connected resources can be served with 2 GB heap size. In a clustered installation with tens of connected resources we highly recommend to use 4 GB heap size.

JVM settings

JVM tuning aims to minimize GC pauses. We offer two main strategies on GC tuning:

  1. Peak SNAMP performance is the first priority and there are no pause time requirements (or pauses of 1 second or longer are acceptable)
  2. SNAMP response time is more important than overall throughput

You may select the most convenient strategy based on your enterprise IT policies.

In most scenarios, number of monitoring & management tools are fixed in time (i.e. number of clients are fixed). If that is your case - choose the second strategy.

According to memory calculation methodology you may specify minimum and maximum Java memory:

We recommend you not to specify PermGen settings

Additional JVM settings can be specified in EXTRA_JAVA_OPTS environment parameter. The following example demonstrates setup of G1GC garbage collector:

export EXTRA_JAVA_OPTS="-XX:+UseG1GC"

More information about memory tuning:

Memory utilization profile

All the Java objects created during SNAMP execution can be divided by its lifecycle:

Short-lived objects are being created for each attribute request or operation execution from monitoring & management tool, and notification delivery to monitoring & management tool. These objects are never being placed into Old Generation but require a right tunes size of Young Generation Heap (Eden and Survivor spaces). The number of short-lived objects depends on the number of requests per second.

Long-lived objects are being created for each connected managed resource and gateway. So, gateway instance and resource connector instance are long-lived objects. Changing of SNAMP configuration causes releasing long-lived objects in Old Generation Heap (Tenured space). Therefore, if you expect frequent reconfiguring then setup the large OldGen heap (to avoid pauses).

Throughput first

If peak application performance is the first priority and there are no pause time requirements (or pauses of 1 second or longer are acceptable), then select the parallel collector with -XX:+UseParallelGC. You might also specify -XX:+UseParallelOldGC if you expect frequent SNAMP reconfiguring.

Also, you can specify -XX:GCTimeRatio=<N> JVM option. For example, -XX:GCTimeRatio=19 sets the goal of 1/20 or 5% of the total time in garbage collection.

Response time first

If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately one second, then you may choose one of the following collectors:

Number of cores

Each gateway or resource connector uses its own isolated thread pool.
So, recommended number of cores (k) is based on the following metrics:

SNAMP represents multichannel Queuing System so Queuing Theory is applicable for necessary computations:

  1. Workload intensity:
  2. Downtime probability:
  3. Availability:

Availability formula contains the required number of cores in indirect form. There is no way to reduce this formula. Therefore, you can use the following simple JS program (use NodeJS or any other JavaScript interpreter) for computing required number of cores:

//source data
var lambda = 50;
var t = 0.1;
var P = 0.999;

//computation
function fact(x){ return x > 1 ? x * fact(x - 1) : 1; }

var rho = lambda * t;

var k = 2;
while(true){
    var sum = 0;
    for(var i = 0; i <= k; i++){
        sum += Math.pow(rho, i) / fact(i);
    }
    sum = 1 / sum;
    sum = sum * Math.pow(rho, k) / fact(k);
    sum = 1 - sum;
    console.log("Availability %s k %s", sum, k);
    if(sum >= P) { console.log("Required number of cores %s", k); return;}
    else k += 1;
}

Examples:

  1. λ = 50 rps, t = 0.1 seconds and expected availability is P=0,999 (99,9%) then required number of cores k = 14
  2. λ = 2 rps, t = 0.3 seconds and expected availability is P=0,99 (99%) then required number of cores k = 4

Many modern CPUs support simultaneous multi-threading (SMT) when one physical CPU core may process two (or more) threads in parallel. In this case, number of cores means number of logical cores.

Thread pool size

It is possible to configure internal thread pool of some gateways and resource connectors. See Configuration for more information about thread pool configuration parameters.

Optimal max thread pool size should be equal to . Each thread might be used as a separated channel for handling requests.

For example, if workload λ = 50 rps, t = 0.1 seconds and expected availability is P=0,999 (99,9%) then required number of threads is S=14. Therefore, the required number of (logical) cores k = 14/1.5= [9.3]=10. The savings on the number of cores is 28%.

Scalability

SNAMP is a stateless component in your IT infrastructure. Therefore, it is very easy to perform horizontal scalability. Just append the additional nodes into the SNAMP cluster. For more information about SNAMP Cluster configuration, see Clustering section in Installation Guide.