[JIRA] Updated: (SSPCPP-332) Session cache slows down if large numbers of sessions with a single NameID are created
Scott Cantor (JIRA)
noreply at shibboleth.net
Thu Mar 29 15:07:17 BST 2012
[ https://issues.shibboleth.net/jira/browse/SSPCPP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Cantor updated SSPCPP-332:
--------------------------------
Fix Version/s: 2.5
Remaining Estimate: 2 hours
Original Estimate: 2 hours
> Session cache slows down if large numbers of sessions with a single NameID are created
> --------------------------------------------------------------------------------------
>
> Key: SSPCPP-332
> URL: https://issues.shibboleth.net/jira/browse/SSPCPP-332
> Project: Shibboleth SP - C++
> Issue Type: Improvement
> Components: Session Cache
> Affects Versions: 2.0, 2.1, 2.2, 2.2.1, 2.3, 2.3.1, 2.4
> Reporter: Scott Cantor
> Assignee: Scott Cantor
> Priority: Minor
> Fix For: 2.5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the commits
mailing list