How to benchmark OX for a large scale deployment

1. How to benchmark OX for a large scale deployment OX was designed from the ground up to support clustered deployments. The application is stateless: no HTTP sessions are ever used. Even in a two-step authentication, it is not assumed that step one and step two will be handled by the same server. For this reason, OX can be clustered with any load balancer algorithm, for example, round-robin or failover. Authentication services are only as robust and performant as their underlying persistence mechanisms. OX uses the LDAPv3 interface for persistence of configuration, user data, and session information. The best two open source LDAP servers are OpenDJ and OpenLDAP. The best non-open source LDAP server is UnboundID. UnboundID also offers an LDAP proxy. To maximize the performance of an LDAP server, the entire dataset must be stored in memory–including the data and the indexes. Even for write performance, keeping the dataset in memory (and proper indexing of course), is necessary. For a large scale deployment, where the entire data set cannot be stored in one LDAP server’s memory, the best strategy is to split the data up in two servers.

2. For example, store users with last name A-M in one set of servers, and last name N-Z in another set of servers. In this case, the Unbounded proxy can use a cross-sever “global” index to route requests to the respective server that holds the entry. OpenID Connect and UMA offer many endpoints to benchmark. The OpenID Connect endpoints are: Authorization endpoint Token endpoint userinfo_endpoint clientinfo_endpoint check_session_iframe end_session_endpoint Registration endpoint validate_token_endpoint

3. The UMA endpoints are: dynamic_client_endpoint Token endpoint User endpoint Introspection endpoint resource_set_registration_endpoint permission_registration_endpoint rpt_endpoint authorization_request_endpoint Scope endpoint  Furthermore, ox Trust provides SCIM endpoints, which can be used for identity and credential management, and provides additional interactive business logic. One important consideration for scalability is logout. For example, millions of clients polling repeatedly to make sure their session is still valid is a waste of valuable server resources. OpenID Connect defines a JavaScript session management mechanism. In this schema, JavaScript is inserted into each web page, and this polls a local browser flag to find out if another tab has logged out.

4. The approach can be problematic if the tab is not present when the logout occurs (i.e. the application may not be notified of the logout). If this mechanism is deemed insufficient for the requirements, an alternate logout strategy will need to be devised. Normally this may include using a call back to the registered back-end applications either in serial or parallel. Benchmarking is an interactive process where the results of one iteration are used to optimize the starting configuration of the next iteration. The components of the infrastructure need to be tested individually. It is then important that the tests try to replicate the expected usage patterns. For the OX APIs, Gluu can assist in the creation of test data, generation of the load, monitoring of the JVM for memory and connection leaks, and reporting on the resulting throughput. For LDAP, the SLAMD tool is available. This tool provides load generation, measurement, system performance, and throughput reporting. The tool can be customized to include the collection of custom metrics to enable correlation of performance to OX API usage. Another consideration is to run long lived tests to make sure that replication data does not bloat entry size and negatively effect performance. Article resource- http://thegluuserver.wordpress.com/2014/05/16/how-to-benchmark-ox-for-a-large-scale-deployment