APM TCP connection limit K38157145

Hi Michael,

you may check the landing URI's of such in-progress sessions. It happens very often that APM timed out browser session still performing certain API calls which are starting lots of new APM sessions.   

I regulary use a black-list of URI's which should not create a new APM session to avoid exhaustion of the Per-IP limits. 

when HTTP_REQUEST {

	#log "Unset all Temporary and HTTP-Request variables (if exists) on each received HTTP request."
	
	unset -nocomplain req temp
	
}
when ACCESS_SESSION_STARTED priority 170 {

	#log "Fetch the landing URI from APM session."

	set temp(landinguri) [ACCESS::session data get "session.server.landinguri"]

	#log "Checking if the landing URI is eliglible to start a new APM session."

	switch -glob -- $temp(landinguri) {

		"/api.jsp" -
		"/some-other-api.jsp" -
		"/some-api-related-path*" {

			#log "The landing URI is not eliglible to start a new APM session. Redirecting the user to the APM hangup page."

			ACCESS::respond 302 \
							noserver \
							"Location" "/vdesk/hangup.php3"

			#log "Marking the APM session to get killed during HTTP_RESPONSE_RELEASE event."

			set req(kill_apm_session_on_http_response_release) 1
		}
	}

}
when HTTP_RESPONSE_RELEASE {

	if { [info exists req(kill_apm_session_on_http_response_release)] } then {
			
		#log "Passing the ongoing HTTP response to client while killing the APM user session."

		ACCESS::session remove
	}
}

Beside of killing those automated session creations as soon as they start a new APM session, you may also check if certain IPs of Proxy Servers are exhausting the limits regulary. In this case you may take a look to an iRule snipped I used in the past to enforce relaxed APM Per-IP session limits for well-known high traffic sources.

Enforcing individual APM Policy "In Progress Sessi... - DevCentral (f5.com)

Cheers, Kai