Instance performance may be affected when:
- an integration makes a request with basic authorization that creates a session
- the integration makes a new request with a different session cookie or no session cookie
Each session lives up to the session timeout for the system, consuming memory and resources.
Steps to Reproduce
- Submit multiple requests to a REST or JSONv2 endpoint.
- Specify basic authorization credentials in each request, but do not specify a session cookie.
Note that multiple sessions are created on the instance and wait until session timeout: https://<instance>.service-now.com/xmlstats.do?include=sessions
Alternatively, if an instance is not on a pre-Eureka version:
- Open an instance that:
- is not configured to throttle inbound requests
- has no SOAP session timeouts set
- Configure a 3rd Party Web Service to open a new session for each new transaction request.
- Do one of the following:
- send an excessive amount of simultainous Web Service transactions
- send transactions that do not close the session after the transaction is complete and the default session timeout is over 4 hours
Sessions build up to the point of memory exhaustion and cause instance performance degradations. The platform should throttle inbound transaction amounts or ensure SOAP sessions have a short timeout duration and prevent the instance performance degradations.
Note: This problem can also be encountered if the integration is not configured to use a SOAP user to create SOAP specific sessions.
Depending on the cause of the excessive sessions, one or more of the following can help you use your integrated service without affecting instance
- Ensure that the integration is not using Guest session. Instead, use a defined SOAP user with restricted roles. Configure the integration to enable improved integration management and performance.
- Set a low SOAP session time out using glide.soap.request_processing_timeout. For more information, see SOAP Session Management and Reporting.
- If the integration is creating many small repeat transactions and opening a new session for each transaction, configure the integration to use persistent HTTP sessions.
- Develop your integration to use a persistent session
If you are able to upgrade, review the Fixed In field below to determine the versions that have a permanent fix to this issue.
Subscribe to this known error article (click the Subscribe button at the top of the article) to receive notifications when more information is available about this issue.
Related Problem: PRB648984