Session cache slows down if large numbers of sessions with a single NameID are created
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Load testing with a common NameID across many sessions (e.g. 1000+) seems to slow down the creation of new sessions dramatically. I'm speculating this is because the code uses a serialized data structure to store the sessions active for a given NameID in a single storage context. Creation in that case requires deserializing a large object, modifying it, reserializing back to XML, and then store back, with the size of the XML growing the whole time.
In the ODBC, case it eventually blows through the column size at some point, probably before it gets big enough to slow things down.
This isn't a realistic load, but it probably should be looked at. Since the feature is only needed when SAML logout or NameID mgmt are used, might be worth having an option to just bypass it anyway.
Load testing with a common NameID across many sessions (e.g. 1000+) seems to slow down the creation of new sessions dramatically. I'm speculating this is because the code uses a serialized data structure to store the sessions active for a given NameID in a single storage context. Creation in that case requires deserializing a large object, modifying it, reserializing back to XML, and then store back, with the size of the XML growing the whole time.
In the ODBC, case it eventually blows through the column size at some point, probably before it gets big enough to slow things down.
This isn't a realistic load, but it probably should be looked at. Since the feature is only needed when SAML logout or NameID mgmt are used, might be worth having an option to just bypass it anyway.