This module seems extremely CPU-hungry on the client side. Having an IM block open, even with no active chats, eats over 50% more of one CPU in Safari or Firefox than viewing the same page with the IM block disabled.

Comments

pahariwalla’s picture

pahariwalla commented
Status: Active » Postponed (maintainer needs more info)

What do you have your IM performance options set to ( adminsettings/im) ? I find no noticible change to CUP usage when they are set at defaults. If I change them drastically, like set all the refresh rates to 100 miliseconds (1/10th of a second) then the CPU goes very high.

I would try to reset to defaults and check your CPU, and if you need a faster refresh rate, then adjust them a little at a time and see how it affects the CPU.

greenbeans’s picture

greenbeans commented

Refresh rates were actually set to slower than defaults, since I'm still in development and didn't want to hammer the server -- 6000ms active and 10000ms idle. And this is with no active chats in progress, just the pane sitting there.

EDIT: Is it possible that the current dev version isn't properly respecting refresh rates? Using a previous version (I think the 12/9 version) CPU usage was OK; using the current version not only am I having the CPU spike problem described, but my host blocked me twice for too many requests to the server (which never happened with the earlier version).

greenbeans’s picture

greenbeans commented
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

I've checked this out using Live HTTP Headers in Firefox, and it's definitely flooding the server. It looks like it's the friend list that's not respecting refresh parameters, and basically firing off requests (to /im/friendlist) as quickly as it possibly can.

It seems that this also occurs with the 12/9 version. I'll see if I can track down the issue any more closely.

EDIT: I've figured out the problem but not how to solve it.

If you don't include the friendlist block, the refresh rate setting is never set up, but the friend list refresh AJAX is called anyway.

So the following code (in im.js, line 146) gets called with a timeout of 0:
timer_friendlist = setTimeout ('getFriendList()', Drupal.settings.im_module.friendlist_refresh_rate);

A quick fix is to move the following from line 460 of im.module to line 451:

  $im_settings = array(
    'friendlist_refresh_rate' => variable_get('im_friendlist_refresh_rate', 10000),
    'friendlist_array' => drupal_to_js(unserialize($_SESSION['im_friendlist_array'])),
  );
  drupal_add_js(array('im_module' => $im_settings), 'setting');

But obviously the friend list update is still going to be called even when the block isn't included.... just at a reasonable rate.

A real fix would probably either move the friend list refresh JS to a separate JS file included only with the friendlist block, or have something in the friendlist block's HTML initiate the friendlist refreshes.

pahariwalla’s picture

pahariwalla commented
Assigned: Unassigned » pahariwalla

Yikes ! Wow, sorry I never tested for that. Another real life proof that coders should NOT be the ones testing their code ;-) ... hint hint, sheepish grin

Thanks so much for @greenbeans your time in debugging this. What I think I will do, for a quick fix, is put a conditional in the JS (if friendlist refresh rate > 0 then set the timer). I could, perhaps, make the friendlist's block's PHP code set a switch to "TRUE" in settings for JS to inspect. But if someone wants to want to create their own friendlist block, they would have to make sure they set the switch to TRUE, and also, why complicate things?

I'm also wondering why earlier version(s) did not cause this problem.

I also love greenbeans, that is, the stringbean variety ... especially steamed and then sprinkled with a healthy serving of almond slivers toasted in a pan with lots of butter.

Anyway, much obliged and will get this fix in.

greenbeans’s picture

greenbeans commented

*edges away from the hot pan full of butter*

Thanks for fixing this. It was actually in earlier versions -- I just hadn't tested them without the friendlist block.

vip_sa’s picture

vip_sa commented

I have a problem that this module slows down my site completely. Especially when trying to edit the blocks for IM Friend picker or IM Console. I cannot anything once I try to edit any of those two blocks. I uninstalled the module and my site is back to it's normal self. What can be done to fix this cause I'd love to use this module than any other available.