On Wed, Jan 1, 2020 at 8:43 PM Asela Pathberiya <as...@wso2.com> wrote:
> > > On Tue, Dec 31, 2019 at 6:36 PM Supun Perera <supu...@wso2.com> 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. > @Supun Perera <supu...@wso2.com> As discussed offline, Shall we invest some time to check on this ? Thanks, Asela. > > 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) supu...@wso2.com | (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/ > -- Thanks & Regards, Asela Mobile : +94 777 625 933 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
