Simple Object Access Protocol (SOAP) semaphores control the number of simultaneous transactions that can execute on a ServiceNow application node in parallel with each other. Semaphores are managed by ServiceNow and require no customer administration. You can gauge the transaction capacity of your instance by the number of semaphores available. Low available semaphores indicate that the instance is running close to full transaction capacity.
You can find out how many semaphores you have available by navigating to https://instance-name.service-now.com/stats.do
If you have a low amount of available semaphores, this indicates that the instance is running close to full transaction capacity. Incoming transactions will wait until there are available semaphores since zero means there are no semaphores available to serve the request. When incoming requests occupy all semaphores, new request will be placed in a queue (from Eureka) or rejected (prior Eureka). In some cases, you may have Web Services Integration for incoming soap request that use one semaphore.
If there is an issue with a third party SOAP request to your ServiceNow instance; such as, requesting a flood due to their application problem, the default semaphores will be quickly used up and no user's UI requests can processed efficiently. You can consider separating the SOAP requests to be served by different semaphore sets.
Low available semaphores does not cause performance or availability problems but can be a good indicator of how efficiently your instance is performing.The benefit of separating your SOAP requests is that it will be served by SOAP semaphores. If SOAP semaphores are used up, they won't affect Default semaphores significantly. Separating your semaphore sets is simple, all you have to do is raise a ticket in HI so that ServiceNow support can assist you with your request.
1 Comment
