Cache response types in ProviderInfoView

[fvlima]

Cache response types in ProviderInfoView to avoid database query for each request.

Testing with ab:

After

ab -n 100 http://127.0.0.1:8001/.well-known/openid-configuration
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:        WSGIServer/0.2
Server Hostname:        127.0.0.1
Server Port:            8001

Document Path:          /.well-known/openid-configuration
Document Length:        724 bytes

Concurrency Level:      1
Time taken for tests:   1.466 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      103900 bytes
HTML transferred:       72400 bytes
Requests per second:    68.23 [#/sec] (mean)
Time per request:       14.656 [ms] (mean)
Time per request:       14.656 [ms] (mean, across all concurrent requests)
Transfer rate:          69.23 [Kbytes/sec] received

Before

ab -n 100 http://127.0.0.1:8001/.well-known/openid-configuration
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:        WSGIServer/0.2
Server Hostname:        127.0.0.1
Server Port:            8001

Document Path:          /.well-known/openid-configuration
Document Length:        724 bytes

Concurrency Level:      1
Time taken for tests:   1.930 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      103900 bytes
HTML transferred:       72400 bytes
Requests per second:    51.81 [#/sec] (mean)
Time per request:       19.301 [ms] (mean)
Time per request:       19.301 [ms] (mean, across all concurrent requests)
Transfer rate:          52.57 [Kbytes/sec] received

Approximately ~ 20ms response time performance improvement on average among 100 requests

[suutari-ai]

Shouldn't the cache be invalidated when adding a new ResponseType (or changing existing)?

[fvlima]

Shouldn't the cache be invalidated when adding a new ResponseType (or changing existing)?

@suutari-ai It depends if adding new response types is something that happens with certain frequency. But what I realized is that the response types are fixed (we only associate existing response types for clients that we create), and if new response types will be add, I think that will be generated new migration for that, so, in this situation, a new deploy of the project that uses this lib must be done, and in this scenario, the cache will be reloaded. The tests simulate the cache invalidating, but it was made just for the tests

[kelkarajay]

@juanifioren Hey, are there plans to get this merged for the next release? The performance improvement seems nice

[juanifioren]

Thanks for the contribution and discussion. We know have on develop OIDC_DISCOVERY_CACHE_ENABLE setting to control this behaviour. Will be available on next version. CC @fvlima @kelkarajay

[kelkarajay]

@davidbeermann ^