My Web host disabled the admin account on my Drupal site for a while today because of extremely large updates to the sessions table that they said were threatening the stability of the shared server. I took a look at an example of these enormous queries (my Web host sent this) and saw more examples by browsing the sessions table. I think I see the problem, but I need to know more about Drupal sessions to fix it - specifically, how Drupal decides what to save as sessions data. I'm a co-maintainer of the phpFreeChat module, and it appears to be data from phpFreeChat that is causing the sessions data to expand so enormously. Drupal is saving vast amounts of extraneous phpFreeChat data that doesn't need to be there at all. The Drupal login name is used by phpFreeChat, but other than that, it has nothing to do with the user's session and nothing in phpFreeChat needs to be saved. To fix this problem, I need to know how Drupal decides what to save as sessions data, and in what source code file this is done (so I can modify it to ignore phpFreeChat). Could someone give me some insight and point me in the right direction? My community really likes phpFreeChat and I don't want to lose my hosting account. Thank you in advance. - Sheryl
On Tuesday 23 December 2008 8:53:49 pm Sheryl (Permutations Software) wrote: *snip*
To fix this problem, I need to know how Drupal decides what to save as sessions data, and in what source code file this is done (so I can modify it to ignore phpFreeChat). Could someone give me some insight and point me in the right direction? My community really likes phpFreeChat and I don't want to lose my hosting account.
Thank you in advance.
Drupal's session handling is really not that complicated. It saves whatever is in $_SESSION to the sessions table at the end of each page request, per PHP standard. That could be almost no data or could be a megabyte of crap depending on what modules decide to stick stuff in there. If the phpFreeChat module has a lot of data in there, I'd look at the module to see what it's doing with $_SESSION. It may be storing data there it doesn't need to and/or not removing data later on when it doesn't need it anymore. It really depends on the modules you have installed. OG, for instance, stores the complete node of the current group a user is viewing in the session, which makes the session table get really big (far too big, IMO). Other modules don't store more than int or two in the session, if that. If you look in includes/session.inc you'll see the entirety of the code. As I said, it's really not very complex. -- Larry Garfield larry@garfieldtech.com
If the phpFreeChat module has a lot of data in there, I'd look at the module to see what it's doing with $_SESSION. It may be storing data there it doesn't need to and/or not removing data later on when it doesn't need it anymore. It really depends on the modules you have installed. OG, for instance, stores the complete node of the current group a user is viewing in the session, which makes the session table get really big (far too big, IMO). Other modules don't store more than int or two in the session, if that.
OG used to do that, but has changed in D6 and about to be released D5. We only do that for authenticated users now, and it gets cleared out when user visits a non group page. Sheryl - just call session_save_session(FALSE) and Drupal will not save anything to sessions table. You should explore any ramifications of this for other modules.
Moshe Weitzman wrote:
Sheryl - just call session_save_session(FALSE) and Drupal will not save anything to sessions table. You should explore any ramifications of this for other modules.
Thank you, I will try this. That's a lot easier than trying to figure out what phpFreeChat is saving to $_SESSION.
OG used to do that, but has changed in D6 and about to be released D5. We only do that for authenticated users now, and it gets cleared out when user visits a non group page.
What does OG stand for? Many thanks! - Sheryl
Moshe Weitzman wrote:
Sheryl - just call session_save_session(FALSE) and Drupal will not save anything to sessions table. You should explore any ramifications of this for other modules.
Unfortunately, this didn't work. It caused big problems within phpFreeChat itself. I typed one line into the chat, and it repeated itself in a loop forever - I had to exit the chat to abort it. I don't understand why phpFreeChat itself would need the session data saved to the Drupal sessions table since it's a standalone program that shouldn't need Drupal data handling. Maybe I did this wrong? I put the session_save_session(FALSE); line at the top of the module code. Any other suggestions? Thanks. - Sheryl
On Tuesday 23 December 2008 10:09:46 pm Sheryl (Permutations Software) wrote:
Moshe Weitzman wrote:
Sheryl - just call session_save_session(FALSE) and Drupal will not
save anything to sessions table. You should explore any ramifications of this for other modules.
Unfortunately, this didn't work. It caused big problems within phpFreeChat itself. I typed one line into the chat, and it repeated itself in a loop forever - I had to exit the chat to abort it.
I don't understand why phpFreeChat itself would need the session data saved to the Drupal sessions table since it's a standalone program that shouldn't need Drupal data handling. Maybe I did this wrong? I put the session_save_session(FALSE); line at the top of the module code.
Any other suggestions?
Thanks.
- Sheryl
It sounds like phpFreeChat (that's a 3rd party system with bridge module?) is doing something with the session itself, perhaps? Check through its code and see where it is saving what to the session. It may have a bug in it itself, or may be doing something that conflicts with Drupal's session logic. -- Larry Garfield larry@garfieldtech.com
On Tuesday 23 December 2008 9:20:52 pm Moshe Weitzman wrote:
If the phpFreeChat module has a lot of data in there, I'd look at the module to see what it's doing with $_SESSION. It may be storing data there it doesn't need to and/or not removing data later on when it doesn't need it anymore. It really depends on the modules you have installed. OG, for instance, stores the complete node of the current group a user is viewing in the session, which makes the session table get really big (far too big, IMO). Other modules don't store more than int or two in the session, if that.
OG used to do that, but has changed in D6 and about to be released D5. We only do that for authenticated users now, and it gets cleared out when user visits a non group page.
Ah, good to hear. That's still going to be a few hundred meg for my site, though. :-) What's the logic for that? Just to avoid node_load time? -- Larry Garfield larry@garfieldtech.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Larry Garfield schrieb:
On Tuesday 23 December 2008 9:20:52 pm Moshe Weitzman wrote:
If the phpFreeChat module has a lot of data in there, I'd look at the module to see what it's doing with $_SESSION. It may be storing data there it doesn't need to and/or not removing data later on when it doesn't need it anymore. It really depends on the modules you have installed. OG, for instance, stores the complete node of the current group a user is viewing in the session, which makes the session table get really big (far too big, IMO). Other modules don't store more than int or two in the session, if that.
OG used to do that, but has changed in D6 and about to be released D5. We only do that for authenticated users now, and it gets cleared out when user visits a non group page.
Ah, good to hear. That's still going to be a few hundred meg for my site, though. :-) What's the logic for that? Just to avoid node_load time?
This is IMNSHO still a horrible design decision. Session data is updated every page view and storing the node in there will increase the traffic between Web front ends and mysql server (and the mysql master and the mysql slaves, if you are set up like this) quite a bit. If you need to keep the OG context, you should only store that context and not all other node metadata in the session. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklRvtAACgkQfg6TFvELooRvZgCgsckMGnEWW24WJUAX6MZCLTnW sB0AoJ9BdtLqfqLKon/2EYAS0T8weCPs =CUuJ -----END PGP SIGNATURE-----
This is IMNSHO still a horrible design decision. Session data is updated every page view and storing the node in there will increase the traffic between Web front ends and mysql server (and the mysql master and the mysql slaves, if you are set up like this) quite a bit.
Agreed. Committed - http://drupal.org/cvs?commit=160680. You guys are good at undressing a guy on a huge mailing list.
If any of you guys want to take a break from dissecting OG, I'd deeply appreciate thoughts and ideas about my sessions problem. Some questions: 1. I put the session_save_session(FALSE); line at the top of the phpFreeChat module code, and it broke phpFreeChat. Was this the right place to put it? 2. How could phpFreeChat - a standalone program - be dependent on what Drupal saves to its sessions table? Seems to me it can't. That's why I think something must have been wrong in how I tried to disable sessions writing. Thank you. - Sheryl
On Tuesday 23 December 2008 11:29:15 pm Sheryl (Permutations Software) wrote:
If any of you guys want to take a break from dissecting OG, I'd deeply appreciate thoughts and ideas about my sessions problem. Some questions:
1. I put the session_save_session(FALSE); line at the top of the phpFreeChat module code, and it broke phpFreeChat. Was this the right place to put it?
2. How could phpFreeChat - a standalone program - be dependent on what Drupal saves to its sessions table? Seems to me it can't. That's why I think something must have been wrong in how I tried to disable sessions writing.
Thank you.
- Sheryl
You already posted that in an earlier message. There's no need to repeat it only a few moments later because the thread forked. As for "standalone program", remember that there is only one session for the entire PHP process, and it gets saved only once. If phpFreeChat is using the session it may be doing its own session starting and closing and saving, or at least trying to. If so, it would not surprise me at all if that collides with Drupal. -- Larry Garfield larry@garfieldtech.com
Larry Garfield wrote:
You already posted that in an earlier message. There's no need to repeat it only a few moments later because the thread forked.
Sorry.
It sounds like phpFreeChat (that's a 3rd party system with bridge module?)
Yes. I'm a co-maintainer on the bridge module.
is doing something with the session itself, perhaps?
It looks to me like phpFreeChat is never clearing out session data, so it ends up saving info about the last x chats the person logged into (e.g. the other users in the chat, the available chatrooms, etc.). Maybe some of this is needed for current chats, but I can't see how it's needed for historical chats. This $_SESSION data grows over time until it's enormous, which is why saving it to the sessions table was creating problems on the server.
Check through its code and see where it is saving what to the session.
It would be very hard for me to figure out what it's saving to $_SESSION and why (what's necessary and what is not). It's a big, complicated program. That's why I really liked Moishe's suggestion of just disabling all writes to the sessions table in Drupal. And it seems to me that it should have worked, but it didn't, so I think there is something wrong with how I implemented it.
As for "standalone program", remember that there is only one session for the entire PHP process, and it gets saved only once. If phpFreeChat is using the session it may be doing its own session starting and closing and saving, or at least trying to. If so, it would not surprise me at all if that collides with Drupal.
I see what you're saying, but there doesn't seem to be any conflict as long as the $_SESSION variables are saved to the sessions table. But when I add the line session_save_session(FALSE); to the top of the bridge module, suddenly phpFreeChat doesn't work. That doesn't make any sense because (theoretically - if I did it right) this just prevents saving the $_SESSION variables to a table that phpFreeChat doesn't use in the first place. So I feel sure I'm doing something wrong in how I'm turning off writes to the sessions table - but I don't know what. Thanks for your feedback. - Sheryl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sheryl (Permutations Software) schrieb:
Larry Garfield wrote:
Check through its code and see where it is saving what to the session.
It would be very hard for me to figure out what it's saving to $_SESSION and why (what's necessary and what is not). It's a big, complicated program. That's why I really liked Moishe's suggestion of just disabling all writes to the sessions table in Drupal. And it seems to me that it should have worked, but it didn't, so I think there is something wrong with how I implemented it.
Earlier you wrote: 1. I put the session_save_session(FALSE); line at the top of the phpFreeChat module code, and it broke phpFreeChat. Was this the right place to put it? No, apparently not. It is hard to guess what went wrong without an error message, though. I'd try to put the statement into various hooks (init, exit, ...?) and see which works. Few people will be inclined to debug the whole phpFreeChat script for you. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklR72gACgkQfg6TFvELooQeqwCfZHxhCv2sC0e/XY9knEmd6h96 nQsAoJjECuPSlLoZz3IbX4P2NQpJAhGg =6AWu -----END PGP SIGNATURE-----
I took a quick look at the module and found this in phpfreechat_room: if (is_numeric($user->uid)) { $_SESSION['drupal_user'] = $user; } This creates a lot of overhead. The user object can become really large depending upon what different modules are doing things with it. I looked through the code and the only part of the user object I see being used is $user->uid in phpfreechat_prepare_params(). I don't even see any real reason to store the uid, since you have the global $user that is going to be available for that session. I would say a good starting point is dumping that all together, since you have a global $user that gets loaded when the session is loaded. Jamie Holly Sheryl (Permutations Software) wrote:
If any of you guys want to take a break from dissecting OG, I'd deeply appreciate thoughts and ideas about my sessions problem. Some questions:
1. I put the session_save_session(FALSE); line at the top of the phpFreeChat module code, and it broke phpFreeChat. Was this the right place to put it?
2. How could phpFreeChat - a standalone program - be dependent on what Drupal saves to its sessions table? Seems to me it can't. That's why I think something must have been wrong in how I tried to disable sessions writing.
Thank you.
- Sheryl
Jamie Holly wrote:
I took a quick look at the module and found this in phpfreechat_room:
if (is_numeric($user->uid)) { $_SESSION['drupal_user'] = $user; }
This creates a lot of overhead. The user object can become really large depending upon what different modules are doing things with it. I looked through the code and the only part of the user object I see being used is $user->uid in phpfreechat_prepare_params(). I don't even see any real reason to store the uid, since you have the global $user that is going to be available for that session. I would say a good starting point is dumping that all together, since you have a global $user that gets loaded when the session is loaded.
Thanks so much for taking a look. This is part of the legacy code I inherited and did not touch because it was working. I'll try taking it out and see what happens. Many thanks! - Sheryl
Jamie Holly wrote:
I took a quick look at the module and found this in phpfreechat_room:
if (is_numeric($user->uid)) { $_SESSION['drupal_user'] = $user; }
This creates a lot of overhead. The user object can become really large depending upon what different modules are doing things with it. I looked through the code and the only part of the user object I see being used is $user->uid in phpfreechat_prepare_params(). I don't even see any real reason to store the uid, since you have the global $user that is going to be available for that session. I would say a good starting point is dumping that all together, since you have a global $user that gets loaded when the session is loaded.
Jamie - I just want to say that you TOTALLY ROCK!!!! This was the problem. I commented out this code, nothing broke, and the sessions table data returned to normal size (so far so good, anyway). I'm embarrassed didn't look in the module myself. I thought I knew the code well from working on it, and I knew I wasn't saving anything to $_SESSION. I forgot there were some pieces I hadn't touched or even looked at in a long time. Many thanks!!!! - Sheryl
Glad that worked for you! And don't be embarrassed. I have done things like that myself oh so many times. Jamie Holly Sheryl (Permutations Software) wrote:
Jamie Holly wrote:
I took a quick look at the module and found this in phpfreechat_room:
if (is_numeric($user->uid)) { $_SESSION['drupal_user'] = $user; }
This creates a lot of overhead. The user object can become really large depending upon what different modules are doing things with it. I looked through the code and the only part of the user object I see being used is $user->uid in phpfreechat_prepare_params(). I don't even see any real reason to store the uid, since you have the global $user that is going to be available for that session. I would say a good starting point is dumping that all together, since you have a global $user that gets loaded when the session is loaded.
Jamie - I just want to say that you TOTALLY ROCK!!!! This was the problem. I commented out this code, nothing broke, and the sessions table data returned to normal size (so far so good, anyway).
I'm embarrassed didn't look in the module myself. I thought I knew the code well from working on it, and I knew I wasn't saving anything to $_SESSION. I forgot there were some pieces I hadn't touched or even looked at in a long time.
Many thanks!!!!
- Sheryl
On Tuesday 23 December 2008 11:08:22 pm Moshe Weitzman wrote:
This is IMNSHO still a horrible design decision. Session data is updated every page view and storing the node in there will increase the traffic between Web front ends and mysql server (and the mysql master and the mysql slaves, if you are set up like this) quite a bit.
Agreed. Committed - http://drupal.org/cvs?commit=160680.
You guys are good at undressing a guy on a huge mailing list.
Sorry, Moshe. That wasn't my intent, it just flowed with the conversation. :-( /me crawls back to a corner to stop complaining, at least for a while. -- Larry Garfield larry@garfieldtech.com
participants (5)
-
Gerhard Killesreiter -
Jamie Holly -
Larry Garfield -
Moshe Weitzman -
Sheryl (Permutations Software)