Do RUM Traffic Control and Overload Prevention use the same session sampling algorithm?

Platform Real User Monitoring
1

Hi Community,

I’m trying to better understand how Dynatrace RUM Classic handles session sampling, particularly the relationship between Traffic Control, Overload Prevention, and the server-delivered multiplicity (mp) value.

According to the documentation, both mechanisms reduce the number of captured user sessions:

  • Traffic Control allows administrators to configure the percentage of sessions to capture.

  • Overload Prevention dynamically reduces captured sessions when the environment exceeds its configured user-actions-per-minute limit.

The documentation also states that overload prevention excludes entire sessions to preserve the statistical representativeness of rate metrics.

This raises a few questions:

1. Do both mechanisms use the same session-selection algorithm?

If Traffic Control is configured to capture 50% of sessions, and Overload Prevention dynamically reduces capture to 50%, is the underlying session-selection algorithm the same?

Or does Overload Prevention use a different approach to deciding which sessions are excluded?

2. How are the two mechanisms combined?

For example, if Traffic Control is configured to 100% but Overload Prevention reduces the analyzed-session percentage to 80%, how is the effective capture decision calculated?

Are these independent sequential checks, or does Dynatrace calculate a combined effective sampling rate?

3. What exactly does multiplicity (mp) represent?

In iOS OneAgent diagnostic logs, I’ve observed sessions receiving mp=0 and mp=2.

A session receiving mp=0 becomes inactive, and its recovered crash report is skipped.

I’m particularly interested in understanding:

  • How does the server calculate multiplicity?

  • Does mp participate in session selection, statistical extrapolation, or both?

  • What does a positive value such as mp=2 represent?

  • How does multiplicity relate to Traffic Control and Overload Prevention?

4. How is statistical representativeness preserved?

The documentation states that rate metrics, such as crash rate, should remain statistically representative when Overload Prevention excludes entire sessions.

Does this rely on random session selection, weighted sampling, or another algorithm?

I’m looking specifically for the documented or confirmed internal behavior of RUM Classic, ideally for Dynatrace Managed.

I have reviewed the following references:

These explain the purpose and observable effects of the mechanisms, but I haven’t found a detailed explanation of how the algorithms interact.

I’d appreciate any technical insights or additional documentation.

Thanks!

Regards, Deni

2

Hello @deni

I can grasp the following, yet it is possible that another individual may have more knowledge regarding this matter.

  • Traffic Control selects an “evenly distributed” share of sessions.
  • Overload Prevention throttles at the cluster side, and the documenttion says sessions are captured fully or not at all.

Regards,

Babar Qayyum

3

The handling of Cost Controll and Overload Prevention is handled differently for RUM web and mobile.

On mobile the Cost Controll is a dice roll on agent side weighted to the set percentage on that decides if a session is sampled or not. Overload Prevention is another dice roll ontop of the sessions that remained. Multiplicity is the Overload Prevention setting applied on agent side. 0 means no session is sent, 2 only every 2nd session, 4 only every 4th etc.

For web the decisions happen on beacon endpoint side, but I do not have as deep knowledge for web as for mobile.