nitty gritty JVM/CF type question: when a new user...
# adobe
m
nitty gritty JVM/CF type question: when a new user hits a CF server and a session is created for them, how much RAM is allocated for that user?
I ask because we're doing some load testing and seeing the RAM on our web servers climb over time until they die. My guess is because the memory isn't being released, and I'm trying to see if that's the case how much memory we would expect to be claimed just by virtue of having that number of users, or if the usage is much higher than that expected number which might indicate a memory leak on top of whatever memory is allocated as expected
d
Are you storing anything in the session or just the session created by CF?
r
Depends on how much information you store in the session for each user/session, on top of what CF creates.
👍 1
d
Is the number of logged in users climbing over time? Or is memory usage going up with the same number of connected users?
r
In some of our apps we store a token in the session which we then use to query a database table that contains the information we need instead of storing it all in the session.
m
@dougcain yes, unfortunately. We hope to move from this to something like @Rodney describes where session is just an id and all session data is in Redis.
👍 1
@Rodney that makes a lot of sense. I wasn't sure if CF was like what I (think) remembered reading about some other languages years ago (not sure if it was php or ruby or what) that would allocate something like 2MB per user right off the bat "just in case". And CF may well be the same but it may be something like "well... the session scope itself takes 512 bytes of memory", and then "plus whatever you start adding to it"
I think our main issue is what we're putting in there (which can end up being a lot). Probably worth solving the known issue there before jumping at shadows related to potential memory leaks 😄
thanks, all
@Dave Merrill yes, but it's because we retain our sessions for 50 minutes after last request (which is a long time). That plus stuffing lots of things in the session I think is our culprit
m
Mith, right now I am unaware of any known memory leaks. A few things though, as garbage collection occurs you can see memory go up and down. Sometimes it just seems like it is climbing forever, but then should drop back down. If its taking your server down you might consider tuning template info and/or GC settings. There's folks in the community like @cfwhisperer and @carehart who are absolute wizards at that kind of thing.
m
👍 My guess is that if there were any memory leaks, they'd be in our application code rather than in CF itself 🙂
c
Thanks for the kind regards, @Mark Takata (Adobe). @mithlond, I'd concur with what's been said so far: no, there's not some large chunk of memory that CF takes on each new session, but yes if you PUT stuff into the session that WILL take the size of memory that thing takes. 🙂 And yes, depending on your sessiontimeout, CF (the JVM) will HOLD that memory "in use" until the session times out. And as you may know, your 50-min timeout does not mean "no session lasts more than 50 mins". Instead, a session will last up to 50 mins beyond the time the user (for that session) ran a CF request on the server...so a session could last for hours. (more to come from me in a moment)
To that last point, I will note finally that you should beware the assumption that your sessiontimeout is 50 mins. That may well be what you have in your CF Admin, but it can be overridden in your application enabling sessionmanagement and setting its own sessiontimeout (in application.cfc or application.cfm, or technically in any page if it were to do a cfapplication tag). And consider also that even if you say "yeah, I'm looking at the application.cfc/cfm for our app", beware that (as you may know) you can have a subfolder under that, which could have its OWN application.cfc/cfm. And THAT could also enable sessionmanagement and have yet a DIFFERENT sessiontimeout...or have NO sessiontimeout, in which case it defaults to whatever is set in the CF Admin. That CF Admin sessiontimeout does DEFAULT to 20 mins, but anyone with admin could change it (or could have changed it years ago)--and to any number of seconds, minutes hours, and even DAYS. And perhaps no one noticed or thought it matters, because "you set the sessiontimeout in your code". Just beware, if you don't, then you inherit that timeout.
Someone may wonder, how could I know how many sessions I have, or how large they are. I'll point out that both the CF Performance Monitoring Toolkit (PMT, for CF2021 and 2018, Std and Enterprise) tracks that, as does the older CF Server Monitor (for CF2016 and earlier, Enterprise only), as does also FusionReactor. There are also the undocumented CF java objects, one of which can show a session count. I did a blog post pointing out more on that, including an app created in 2009 by Mark Lynch, ServerStats, which you can still get. I've not tested it in a few years. Now, as for tracking the memory USED per session, or in aggregate, that's another beast entirely. The old CF Server Monitor offered a "memory tracking" feature--which when most enabled it, it would kill their CF instance, so not a good idea. The new PMT offers a more intelligent way to control such tracking (not enabled by default), which you may want to look into. FR does not track the size of each or all sessions (because again, doing that can be challenging.) All that said, tracking simply the session COUNT alone (per app or in total) can often be useful enough to spot problems. I've helped people see the count was shockingly large (tens or even hundreds of THOUSANDS of active sessions), and those are often caused by bots. That's again an entirely different topic with its own solutions, as I discussed years ago in this post. While it's 16 years old, the concepts still apply, and I really should reprise it with new info/tools. Anyway, hope that's helpful.
❤️ 2
👍 2