I have a lot of variables under Session object instantiated on session opening event.
I’m thinking to optimize the Session objects by moving them out to separate class (say class G) and accessing them like: pdf_file = Session.G.PDFFiles(1) and etc.
So, session object will store a minimum required variables.
Is this approach may optimize the memory footprint for web app?
I’m faced with increased memory usage for two users (from 500 MB to 1.2 GB within a 6 hours of continues usage in Ubuntu server 20.4 LTS) and looking for an optimization of variable’s usage first. The application is getting slower and slower and running fine after logout-login and simple app service restart…
Sure, there could be other areas to look for an optimization, but my eyes stopped at Session object. 
Thanks!
What I’m doing is accessing data that is not frequently used as required. I was storing a lot of data pretty much as you describe.
@Ricardo_Cruz enlightened me the other day and told me to try to avoid storing too much data in memory. Not his exact words but that’s the spirit of what he told me. This made me re-think my design and I’m cleaning things up as to only store the really necessary data in session.
1 Like
I think it was more related to avoid using some kind of global properties in the App object (using a DB, Redis or something instead for them), to avoid issues when running more instances behind a load balancer. So the app can scale horizontally without depending on those globals.
Please check the Web app optimization documentation. There is a section about Memory leaks, it sounds like the issue you’re facing.
If you’re using the same amount of objects, it shouldn’t have a big impact moving them away from the Session instance.
1 Like
The App object have few variables, and as @Ricardo_Cruz said ‘it shouldn’t have a big impact moving them away from the Session instance’, then I think this is something related to destroying the arrays and classes.
May be closing all objects manually at the end of their life cycle will stop the increasing memory usage, even if they destroyed automatically by Xojo runtime.
2 Likes
Some additional docs that can help: