queries to unconfigured providers

Thanks for the report. We're looking into this. There's a couple of quick notes I can respond with that should help alleviate some of the concern as well as some things I can see we could do better:
1) The query is on our JFBConnect user_map table. I'm assuming all 800k of your users have not registered through a social network, so that table is likely very, very small. It's not going over the main #__users table, which would be much larger.
2) You're correct that we don't have indexes on that table, which surprises the heck out of me. That will be corrected in an upcoming release. Again though, that will only help when you have a large number of users that have connected with a social network only.

With that said, we can't find an instance where all of those queries for each network would be loaded on the front-end under normal circumstances. Can you let me know:
a) Are you seeing those queries on every page load?
b) Is it happening for guests or logged in users? If logged in, how are they logged in: through Joomla or a social network?

Let us know any other details you can about how/when you see those queries and we'll gladly help investigate more. We take performance very seriously and never like to be a bottleneck.

Thanks,
Alex

1) JFBConnect user_map table is ~141,746

That's a big table indeed. You have that many users that have authenticated with a social network on your site? If so, you'd be in the top tier of sites using JFBConnect. Congrats

At the moment, I have partially hacked the component and blocked any requests towards unconfigured providers, but this is only a partial solution (I cannot hack any point that produces the query or the component fails).

Honestly, if you're not using the other social networks, you likely can delete the /components/com_jfbconnect/libraries/provider/xyz.php files for each one, like vk.php, windowslive.php, etc. If you're using any features from those networks, like LinkedIn Share, don't delete the file.. but if you have nothing using the network, deleting the file should prevent it from loading.

That's a very dirty solution. We'll have to look into the queries we're doing at authentication to understand why all networks are being queried in that table. I don't have an answer right now as I agree they shouldn't be. If you've done some dirty work already and narrowed down the specific query that's causing the repeatedly look ups, let me know so I can have a jump on things.

Thanks,
Alex

Thanks for the report. We've added this to our to-do list tracker and it will definitely be investigated for the next release. Off-hand, I'm still not sure why we'd request info from each provider, but there's a lot of moving parts, so possible we always missed something.

Alex