On Tue, Dec 31, 2019 at 6:36 PM Supun Perera <[email protected]> wrote:
> Hi All, > > *Problem* > As of now Identity server users database based session data persistence > for storing the user authentication sessions in addition to the > authentication cache. Also, it's recommended to enable the session > persistence to the database due to the limitation of the cache size > available and the distributed caching issues faced with hazelcast. > Even though the database based session persistence solution is working > fine for many customers who have relatively low user sessions created, It's > not the case for some other customers who have the use cases such as having > many user logging on a burst. As an example, students log in on an exam > portal. > > In such cases what we have seen is that the growth of the session table > (IDN_AUTH_SESSION_STORE) would be huge. Even though there are clean up > stored procedures introduce to maintain this table in such cases, it's not > that efficient as the > 1. Clean up procedure will not capture this data until the session expires > time. > 2. Even though the cleanup procedure captured and delete the data, it will > not immediately reclaim the disk space from the database. > 3. Meantime the session data table could be grown to a level ( 200+ GB ) > which will slow down the entire login process. > > *Solution* > 1. Reduce the session object size. (one of the major issues is that the > session object that we will be storing is quite big for a single record.) > Even if we are going for in a memory-based solution (such as Redis). This > need to be addressed prior to that. Since the problem will be remaining > even with an in-memory based solution if the session object we going to > store is quite huge. Also reducing this would absolutely help to improve > the performance of the database based solution as well. Therefore we need > to revisit the implementation and optimise this to reduce the session > object size in the first place. > This is a good point to investigate. I guess we need to verify on duplicates + serialization method which is used by default. Can we invest time on this ? > > 2. The implementation of the session data store should not be limited to > storing with a database-based solution, Rather we should provide an > extensible interface so that could extend and customise the implementation > to plug solutions like Redis, NoSQL databases or any other in-memory > solutions based on customer preference and our recommendation. > With this, we could ship the product with the default behaviour of storing > the session data into the database. However, if the customer is willing to > change the default behaviour for better performance we could provide that > flexibility out of the box. This something already pointed in the issue [1] > as well. however, I guess we need to pay more attention to this and > prioritise this as this would be one of the major pain points that we could > see from the customers. > +1 This also would help to override any plugable serialization way as well based on the user cases. It would be great if we can have such interface in future WSO2IS release. Also; if customers prefer to work on without session persistence (if remember me & SSO timeout are not a major concern) we can come up with simple equation based factor such as idle timeout + number of active users + session object size + optimal memory + session cache capacity to decide whether it can be operate optimally without persistence. Thanks, Asela. > > [1] https://github.com/wso2/product-is/issues/4355 > > > *Supun Perera | **Senior Software Engineer* > (e) [email protected] | (m) +94712235101 | (w) wso2.com > <https://www.wso2.com> > <http://wso2.com/signature> > -- Thanks & Regards, Asela Mobile : +94 777 625 933 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
