About SAP ID Service
SAP ID Service is the central cloud services that covers the process for managing identities and their life cycles within the SAP cloud. With this ID Service, users will be able to set up one SAP identity and leverage single sign-on when browsing SAP websites, using SAP on demand systems, or accessing third-party on-demand applications.
SAP’s ID Service saves time and resources by enabling users to update their profiles only once and requiring just one password to log in to SAP’s various on-demand systems.
With the increasing use of the SAP ID service, we realized that the response times were not optimal for such a central authentication service.
In several analyzes using the SAP JVM Profiler we worked out several hot spots in the code, which had to be optimized.
As an example: there were identical read request to the same document in MongoDB again and again. This document was converted with each reading using the Morphia Google Mappers to a Java object to work only with a few attributes.
The same pattern occurred repeatedly. Also at other code places the same request to backend system was done again and again.
In the first case with the object mapping a solution was implemented relatively easy using a local cache. The latter case several attempts have been made, but not all led to hoped-for success.
Here, too, using a local cache we tried to reduce the queries against the backend. However, it was not possible to keep the cache at request scope. So this cache was discarded.
SAP ID Service offers a variety of ways to authenticate a user. The detection logic with which method a user should be authenticated with is not so simple.
In a revision of this resolution we focus on the “Happy Path” for the four main authentication methods. These requests are processed quickly.
The changes were not limited to coding.
So the connections to the LDAP server has been revised. So far, the LDAP servers have been operated in a master-master replication mode, to distribute the read/write access to all LDAP servers. This replica mode was converted into a master-slave mode. So writes occur only on one LDAP node. In addition, we optimized the connection pooling to the LDAP servers.
Additionally we could sharpen the utilization of all nodes by improving the distribution rules in the load balancer.
In total all these measures achieve a significant improvement in the user log on.
Thus, the response time went down from about 700ms to an average of 80ms.
In parallel, the number of concurrent request has nearly tripled.
Here some graphs from before and after the activation of these changes:
Average Response Time per Server:
Parallel Client Connections:
Number of LDAP Connections per Server: