mPulse Beacon Rate Limiting

Document created by Lauren Younger Employee on Dec 12, 2017
Version 1Show Document
  • View in full screen mode

mPulse includes a safety feature for beacon traffic called rate limiting, that acts to limit incoming beacon traffic to for a single application to a multiple of their contractual beacons per month limit.  This feature helps prevent the mPulse collection grid from being overloaded from an application (app) problem or needle spike traffic surge or from excessive traffic from applications with low limits (such as apps for free or proof-of-concept customers).


Rate limiting works like this - we record the volume of beacons received over the previous hour.  As new session requests are received, we compare the beacon rate over the last 60 minutes to the app's hourly beacon limit (as an example, for a customer with a 1M beacons per month limit, their hourly limit would be 1370 beacons).  If the current beacon rate is less than the limit, we accept the session (and all beacons associated with that session).  If a customer's current rate exceeds their limit, we apply a formula to determine if we should refuse or accept the session - this formula takes into account how much over their limit the app is, a system sensitivity setting and a random factor.  The result is that as an application is more and more over their limit, the greater the chance that we will refuse incoming sessions.  Because the feature includes a random number, rate-limited apps will still receive some new sessions, in addition to receiving beacons from existing sessions.  Rate limited configuration requests will receive either a 420 response code or a rate_limited response.  If the user’s session terminates while they are rate limited, and a new session begins, this new session may be successfully accepted by the system. We do not accept partial sessions.


In practice, customers are unlikely to ever see rate limiting.  There are two scenarios, however, that may cause it to engage:

  • Consistent very high volume; if your application is receiving traffic well in excess (several times) your contractual limit, it may cross the hourly beacon limit threshold during busy times of day.  During the hours of high volume, the beacon volume graph will show periodic dips about 1.5 hours apart - this is the rate limiting system engaging and disengaging.
  • Needle spike traffic surge; if your application receives an extremely large burst of traffic many times over your hourly limit, we may start to rate limit the traffic a few minutes after the start of the surge.

Both of these scenarios can be avoided by engaging with your Akamai representative; for the first scenario, renewing at with a higher beacon volume is recommended.  For the second scenario, a limit increase can be requested in advance of your expected traffic surge, and your traffic will be evaluated over the past month to ensure that a higher limit is safe (for the infrastructure) and will not lead to significant regular beacon overages.


For proof-of-concept (POC) and free customers, rate limiting is more likely.  POCs are set to a moderate limit, and a limit increase can be requested if traffic being collected is being clipped during periods of high volume.  Free customers can receive a higher beacon limit by signing up for a mPulse annual subscription.