Page Load slows when Facebook Connect set to primary

Had the same problem! Fixed it with some epic line of codes. This is my top of fb_connect.js:

Drupal.behaviors.fb_connect = function(context) {

// Logout of facebook when logging out of drupal.
jQuery("a[href^='" + Drupal.settings.basePath + "logout']", context).click(FB_Connect.logoutHandler);

// Support markup for dialog boxes.
FB_Connect.enablePopups(context);

console.log("init");

var events = jQuery(document).data('events');
if (!events || !events.fb_session_change) {
//jQuery(document).bind('fb_session_change', FB_Connect.sessionChangeHandler);
//console.log("init_change_DOM");
jQuery(document).bind('fb_session_change', function (context, session) {
FB_Connect.sessionChangeHandler.call(null, context, session);
});
}
};

FB_Connect = function(){};

// JQuery pseudo-event handler.
FB_Connect.sessionChangeHandler = function(context, status) {
console.log("connetion_init");
jQuery('.block-fb_connect')
.ajaxStart(function() {
jQuery(this).html('

');
console.log("start");
})
.ajaxStop(function() {
jQuery(this).html('');
console.log("stopp");
})
;

// Call the default handler, too.
FB_JS.sessionChangeHandler(context, status);
};

That should fix it ;)

P.S added my fb_connect.js to this post

Rino André Johnsen
rino@nymedia.no
Ny Media AS - www.nymedia.no

If you have a fix, please post a patch.

Hi,

I installed fb module and enabled following sub-modules within it:
1. Facebook API
2. Facebook Apps
3. Facebook Connect
4. FB User Management

Also configured the "Facebook Applications" (../admin/build/fb) page with facebook secret/api keys.

Once done I get "FConnect" button on login page and I can login on site through facebook accounts credentials.
But I am facing following problems while accessing fb module:
1. The Login process is very slow.
2. It is taking too much time to display welcome message after login.
3. Facebook userid is being displayed instead of facebook username as welcome message after login. Though I have set the "Human-friendly, i.e. "John Smith" option in "Username Style for Automatically Created Accounts:" (../admin/build/fb/fb_user)
4. I am also getting following types of errors as well:
a. Failed to get application properties (sam) from Facebook: fb_call_method failed calling admin.getAppProperties. Connection timed out -110
b. Failed to query facebook user info: couldn't connect to host 7. (logged into facebook as 100001512675779)
c. Failed to get Facebook user info for account 100001512675779: couldn't connect to host 7
d. Failed to query facebook user info: connect() timed out! 28. (logged into facebook as 100001512675779)

Can you please suggest if I am missing anything in the fb configuration.

Thanks in advance...

did you go through Readme.txt file?

i'm using fb-7.x-3.x-dev.
i have similar problem that each page load very slow when enabled fb connect module.
The loading time increase from 9xx ms to 7s.

I enabled following modules with one app:
fb
fb_user
fb_connect
fb_app

When i trace into fb_connect_fb, i found the time increased come from fb_get_app.
And fb_get_app seem just use fb_invoke.

Any idea on why fb_invoke is slow?

7 seconds sounds like something must be trying to contact facebook. Under normal circumstances it shouldn't. Can you track it further?

Are you sure fb_devel.module is not enabled?

Hi Dave,
We didn't enable fb_devel module. I forgot to mention that our site is under password protection. Will it cause the api response slow or looping?

Checked from facebook's live status, there is no reported network issue:
http://developers.facebook.com/live_status

Thanks,

I'm not sure what's causing the delay. You tracked it down to fb_invoke, apparently, but that function calls all modules that implement a hook. So you'll have to track it further to find what's actually causing the delay.

i tried to look into the fb_invoke and added a watchdog before and after the function call. I saw there are fb_connect, fb_app,fb_user and many different state(exit, current_app..etc). But i don't see any time difference between the log entries that logged before and after the function call.
Any idea on it?

Hi, just an update, i test it again after a week, we do not see the slow loading page with fb connect now. I think it may relate to facebook's network status.

Thanks.

There's two ways a page can render slow. Client side and server side.

Client side, the javascript contacts facebook to render XFBML tags and lots of other things. So for the page to finish loading might take a while. However... everything else about the page should render quickly. The user should not be stuck waiting for non-facebook parts of the page.

Server side, a network delay could slow some pages. However, if fb_devel.module is disabled, then relatively few server requests should need to contact facebook. So even if there is a network problem, it should affect only a handful of pages, say when you connect or log out. It shouldn't be hitting facebook on every page request. Unless your custom code does so. Modules/fb should not be.

If there is a server-side slowness, and you can track it down, please let me know.

I have the same problem. 3-10 seconds delay on every page request. I'm not yet a drupal geek enough to pinpoint exactly what is happening, but I'm pretty sure it's communicating with facebook on every page request. Delay is longer on a View that contains many nodes - for some reason...

Hi Dave,
We upgraded the fb to latest and have the slow issue again. After further trace, we found that just for the login page, it will call fb_invoke for 46 times. In each fb_invoke, it will call fb_app_fb, fb_connect_fb and fb_user_fb in our case. This operation is happening in each page loading.

The slowness is only occur when fb_app_fb, fb_connect_fb and fb_user_fb are used together. is it possible that there is function call looping?

Thanks,
William

I saw fb_inoke is called for 53 times sometime after login.

I saw fb_inoke is called for 53 times sometime after login.

subscribing... I'm using FB connect and fb user management and it cause the page load so s~l~o~w.....

Hi,
I found the issue is caused by the fb_username_alter in fb.module, which will get the username with FQL from facebook. For a page with a list of user, this function will be called for each user's name. In my case, it try to get the username for each user via FQL and result in very slow respond for a page load.

I patched two file to add a option to disable the feature (return facebook name).
please review.

Thanks

Hi William,
After I patched your patches,

Notice: Undefined index: username_alter in fb_app_edit_form() (line 144 of /home/victori2/public_html/sites/all/modules/fb/fb_app.admin.inc).

error above came up when i try to edit my old apps on:
http://www.victoria.my/admin/structure/fb/app/victoriafb/fb_app

I think duplicate of #1193778: Facebook user name always overrides Drupal username. I think the patch needs work in that you have the setting on a per-application basis, but I think this belongs in the site-wide app settings. Am I right about that?

Also related: #1188256: Cache usernames in fb_username_alter

william.lai tried to apply the patch, got the same error ad #18

Dave - Do you have any clue what can make to pages load so slow?

Hi maxchock, imorenon
That is not an error and it is a notice. Because the username_alter is a new attributes, not exist in old data. After save, this notice should disappear.
To avoid, we can update line 144, from:
isset($data['fb_app'])
to
isset($data['fb_app']['username_alter'])

Hi Dave,
is it possible that one app need to alter username with facebook username while another app doesn't need this "username alter"?

Thanks.

Hi all!

I can confirm slow responses too that are not related to client nor server performance (dedic. server with plenty of torque and new workstation as client)

I tracked down the issue to fb_format_username($user) function. Apparently it needs to connect facebook everytime it fires.
I have stored the variables to session for better access and with this roundup username returns instantly in custom block that displays logged in user's info.

Would be nice that this wouldnt slow down the rest of the page including commenting.

// check that user has logged in
if ($fbu = fb_facebook_user()) {

// get app id from globals - is there better way??
$fbid = $GLOBALS['_fb_app']->id;

// stored variables available in session
//// dump variables
// dpm($_SESSION['fb'][$fbid]['userinfo'][$fbu]);
print($_SESSION['fb'][$fbid]['userinfo'][$fbu]['name']);
}

Using:

- API, apps, connect and canvas pages

drupalforfacebook.org works nice, but it's in Drupal6 platform isn't it?

I can confirm that fb_connect slows down my homepage dramatically in my dev environment. It makes a difference of 7-9 seconds (every page load) for anonymous users if I check the box for "Initialize fbConnect javascript on all (non-canvas) pages. If this site supports multiple Facebook Apps, this may be checked for at most one."

Hi All,
150$ bounty for a submitted patch that will resolve this issue.

BR
Itzhak

Bounties are good! ;)

I think it is the format_username problem which has been reported in at least one other thread. (The last patch there was bad). I'll try to get a working patch. An interesting test would be are all pages slowed equally? If it is the format_username issue you should notice for a example a view which shows a lot of user names would be slower than a page showing a single node.

The other known slow-down comes from fb_devel.module. Normally in development that should be enabled, but not when testing performance/speed.

OK, instead of caching, this patch introduces some intelligence. It attempts to skip the username_alter when theming a username.

The username_alter is important when formatting a username - for example for an email or page title. Not important when theming a username (html markup). Unfortunately Drupal's theme_username() calls format_username() which calls the alter hook.

This patch attempts to keep track of when we are theming a username and skip the alter in that case.

I agree that in addition to this, some caching would be nice. It might be better in core than in fb.module. But either way I think this is the more important fix and that caching can come later.

Please try the patch and let me know.

Does anyone had a chance to review this patch? I had to remove DFF from my site as it was killing my VPS resources.
If anyone will confirm this one is working i would be able to re-install the module,

BR
Itzhak

It looks like the new dev version from 3/14/12 solve this issue, site sped is unaffected when using fb connect.
new dev is working for me, anyone else?

I don't think that patch is in the latest .dev. I was waiting to hear from anyone who's tried it. If the latest build fixes it, it must have been something else.

To be sure, visit it page that has a lot of user names, like a forum page or view table with author field.

I have been testing this issue with FF, IE & Chrome with the llast 4.4.12 dev version
did a comparison for the same pages with same facebok app - once as primary and second as non primary. furthermore i have tested same pages without facebook app at all. all pages took about 3.3 sec to load.

Dave/william.lai I think this issue can be marked as fixed.

I think to reproduce the problem addressed by this patch, you need...

a) a bunch of users who registered via facebook connect.

b) A bunch of posts by those users.

c) A page that displays a bunch of their usernames. Like a view or list of teasers with author name.

So you wouldn't notice this on just any page. And still might not notice if your connection to facebook is quite fast, but would notice for sure if attempts to reach facebook start timing out.

Looks like there's an unescaped call to dpm() in the patch:

dpm(func_get_args(), __FUNCTION__);

which breaks the site if you don't have devel() enabled.

Hi Dave, the patch you posted worked perfectly on my site. Is this patch in the new DEV version released May 2nd?
regards
Alfredo

OK, I take it this is RTBC. And now pushed, so it will be the next .dev build (without calls to dpm()).

Thanks all.