resource hog: mydrupalsite.com/fb_cb/18241/fb_connect/receiver

In order for Facebook Connect javascript to function properly, the browser hits the URL frequently. If you select one application as the "primary" facebook connect app (which is recommended), this javascript will be triggered every page request. Drupal for facebook works this way so that any page can contain XFBML markup.

If you're certain that XFBML will appear only on one page, and you render the facebook connect login block on that page, then you can uncheck the primary checkbox and browsers will stop making those requests on most pages. (At least I think, possibly the presence of facebook connect cookies will change that).

The receiver file is simply a static page. View the source of mydrupalsite.com/fb_cb/18241/fb_connect/receiver to see what it contains. Unfortunately, facebook limits where this file can be placed. For Drupal for Facebook this means the url must contain the fb_cb/NNNNNN portion of the URL. And this in turn prevents us from simply making one static file for the receiver. Since you know in your case that NNNNNNN is 18241, you can save the source of the receiver HTML into a file named fb_cb/18241/fb_connect/receiver. That way, you'll avoid all the overhead of drupal for each of these requests.

Possibly the modules can be improved by creating that file automatically, or a re-write rule could be added to .htaccess to do something similar. I'll give this some thought... and I'm open to other suggestions. Thanks for pointing out just how much overhead it is causing.

On top of that, I added a watchdog message to fb_devel.module for every receiver request. And accidentally I made that watchdog message every single request. That added a lot of overhead and on top of that the referer string is probably to long to fit into the watchdog table, causing even more error messages and overhead.

I just fixed fb_devel.module. But my earlier comment still applies.

Thanks Dave, I think your suggestion of making that a static file, similar to boost is the best suggestion. Or perhaps even to include that file in the js, so it does not have to read it from disk.

Dave, I was thinking of this a bit further, and was just wondering if this ping is used only by logged in users? I guess it is not needed by anonymous at all.

I think even for anonymous users this is requested. I think without it things like the facebook connect login button will not render. Not 100% certain.

Hi,

I've got the same problem, when using IE to access the site, I see around 2 requests to "receiver" every second. This does not happen when using Firefox...

May be there is an error in some javascript? Which script is generating the request?

Thanks
Franco

Facebook generates requests to that script, not drupal. Facebook connect relies on a lot of javascript.

In short, I can't tell you exactly why that's happening. But anyone can track it down and submit a patch, it will be included!

For performance, it's better to make a static receiver file. But due to complications, the path where the receiver is found depends on the node id of the facebook application. If there's an apache rewrite rule wizard out there, maybe you can show me how to automatically rewrite all requests to fb_cb/NNNN/fb_connect/receiver.

Ok, I've removed the session hepler block and the requests disappeared...

I don't seem to need it so I'll leave it off, don't know what the problem is.

Thanks for your comments
Franco

The session helper block is experimental, and meant for one case only. When FBML canvas pages are mixed with iframes, and the browser does not share a session between the two. In other words, don't enable it.