An operator has been asked to troubleshoot a highly busy VS in collaboration with the application team. Which mechanism can be leveraged to avoid a performance issue on the Avi Controller during…

Question

Options

• AModifying the Apdex Criteria in the analytics profile of this VS
• BEnabling a Client Log Filter to log only the IP(s) of the application team
• CAdding a performance boost in the analytics profile of this VS
• DSelecting Client Insights and setting to Passive

• A
  5% (1)
• B
  16% (3)
• C
  5% (1)
• D
  74% (14)

Explanation

Setting Client Insights to Passive removes the overhead of active JavaScript injection into client responses (used for Real User Monitoring), which is a resource-intensive operation on the Avi Controller - especially under heavy traffic. By switching to Passive mode, the controller stops actively collecting client-side telemetry, freeing up processing capacity without completely disabling analytics or troubleshooting visibility.

Why the others are wrong:

• A (Apdex Criteria): Modifying Apdex thresholds only changes how satisfaction scores are calculated - it doesn't reduce the controller's processing workload at all.
• B (Client Log Filter): Adding a log filter for specific IPs actually adds filtering logic to the pipeline; it's useful for scoping log noise but can increase, not decrease, controller processing overhead.
• C (Performance boost in analytics profile): This is a distractor - no such "performance boost" option exists in the analytics profile as a load-reduction mechanism.

Memory tip: Think of it as a "quiet mode" - when the controller is struggling under load, go Passive to stop it from actively doing extra work (JS injection/RUM collection) so it can focus on core functions. Active = more work, Passive = less work.

No community discussion yet for this question.