Performance of /oauth/token endpoint

Hi UAA team 😃

What version of UAA are you running?

version: 4.20.0

How are you deploying the UAA?

locally only using gradlew (osx, 2,6 GHz Intel Core i7)

Preface

Because I wanted to check what is UAA’s limit of token generation, I ran small performance tests, simple wrk call on /oauth/token - nothing fancy. Result was not splendid so I checked for what UAA spend its CPU time, I attached async-profiler and this is the output

UAA, is spending more than 50% of time in org.cloudfoundry.identity.uaa.zone.MultitenantJdbcClientDetailsService.loadClientByClientId

I made small experiment and I added simple “cache” to that class (just ConcurrentHashMap) that holds result of

ClientDetails details;
try {
    details = jdbcTemplate.queryForObject(selectClientDetailsSql, new ClientDetailsRowMapper(), clientId, zoneId);
} catch (EmptyResultDataAccessException e) {
    throw new NoSuchClientException("No client with requested id: " + clientId);
}

and with that piece of code included, UAA behaves a bit better on that path only key signing (here 2048bits) and some fasterxml stuff.

here, I uploaded original SVG files (github don’t allow for uploading svg files in issue) before: https://github.com/KowalczykBartek/tmp-svg/blob/master/slow.svg after: https://github.com/KowalczykBartek/tmp-svg/blob/master/slow-but-better.svg

Question

Is it possible to add some caching on MultitenantJdbcClientDetailsService layer ? Does it makes sense from security point of view (or just any point of view 😄 ) to cache ClientDetails in memory (it can be cached on each instance without any sharing, like Redis or Memcached) ?

thanks !

[mwdb]

@shamus This is an issue in UAA that deserves to be fixed. Instead of two DB requests, UAA is at 14. This considerably costs performance and limits scaling.

Requesting to reopen it.

[mwdb]

We have been looking into the topic of caching also. Our observations are:

• Issuing a client credential token requires 14 calls to the data base, touching the identity_zone and oauth_client_details tables. Details are: 4 calls for identity_zone by id 2 calls for identity_zone by subdomain 8 calls to oauth_client_details by client_id and identity_zone_id

The simplest cache would be to have a request level cache, which avoids redundant calls for the same data. This would already take it from 14 calls to the database to 3.

• For user based tokens like the password grant token numbers are worse: roughly 54 calls. Details are: 20 calls to group_membership 10 calls to oauth_client_details 9 calls to users 15 calls to identity_zone

Similar, with a request level cache this could be reduced to ~ 6 calls.

Caching can be implemented using the Spring cache mechanisms. Concerning the cache implementations, I see the following requirements:

• The cache returns a copy of the cached object to avoid modifications of cached objects
• Within processing a single request, changes to persistent data can be ignored