PS: Not sure if these are related, but below are the only errors I see in the SF Toolbox. There are, however, lots of them!

20 June 2013, 10:07 am
php    file: /simple-press/sp-api/sp-api-primitives.php
line: 611
function: Unavailable
Notice | Uninitialized string offset: 0

20 June 2013, 10:07 am
php    file: /simple-press/sp-api/sp-api-primitives.php
line: 611
function: sp_send_email
Notice | Uninitialized string offset: 0

20 June 2013, 10:07 am
php    file: /simple-press/sp-api/sp-api-primitives.php
line: 611
function: sp_send_email
Warning | Illegal string offset ‘sfmailuse’

First up – the 4 queries are genuine although you should only ever see it run once per page load. I also see no reason why this should be slow in any way. The table itself is not even referenced – just the catalogue. It is probably a good time for us to review the use of this and some other SHOW queries in any case. They may not really be needed any more so I will open a ticket to see if we can remove them.

As to innoDB tables then the only negative I am aware of is that at one point they did not support FULL TEXT indexing which SP makes use of on the sfposts table. However, I believe at some stage support has been added but I am not sure with which version so just check that this is supported in your target version. I am interested to know the results if this change if you go through with it.

Personally I have never played around with MySQL settings but I do know Steve has so he may want to add something.

Sorry I forgot your second post there.

I will look at those. It is probably a data issue with your database we are not covering.

It is probably a data issue with your database we are not covering.  

Can you clarify what you mean by this please? I completely understand if you mean you do not offer general wp/db support. That’s fine, I’m just looking for guidance since the issues seem to be SF related and I don’t know what you mean by, “we’re not covering.” Thanks!

Just my sloppy turn of phrase. I meant simply we are probably trying to load an option setting (from the database) that you have never set and we have not checked for a null or not set condition. That is the usual cause of these annoying notices and/or warnings.

I meant simply we are probably trying to load an option setting (from the database) that you have never set and we have not checked for a null or not set condition.

Thank you for the clarification! Any steps I can take to resolve these errors? Or is this in regard to the sp-api-primitives.php notices/warnings and not the query issues I first addressed?

The notices in the error log.

Jim Said:

| 35996 | tripawds_xxxx | localhost | tripawds_xxxx | Query | 4 | checking permissions | SHOW TABLES LIKE ‘wp_1_sfoptions’ |

Yellow Swordfish said:

It is probably a good time for us to review the use of this and some other SHOW queries in any case. They may not really be needed any more so I will open a ticket to see if we can remove them.

Thank you! I’m happy to help with this any way I can.

I’ve been troubleshooting with our server manager all day. When I deactivate SP, we see pretty consistent stability. Upon activation, we experience random load spikes caused by MySQL eating up system resources with numerous SHOW TABLES LIKE queries on wp_1_sfoptions. We’re logging any queries taking over two seconds, and this one is getting logged a lot, often taking over 5 seconds.

not sure how sfoptions would be that long loading… its one of the quickest for me…  how often are you seeing it per page load?

…how often are you seeing it per page load?

Not sure, how might I determine that?

On a related note, my server guy asked if the SF plugin loads on every page of the site. I presumed it only loads on /forums – our Forums page permalink. Is that right?

boy…  we used to have a built in way to output this debug info, but cannot seem to remember…

will dig around, but may need Andy to weigh in on how to activate it…

On a related note, my server guy asked if the SF plugin loads on every page of the site. I presumed it only loads on /forums – our Forums page permalink. Is that right?

The answer to that is both yes and no! All plugins have to load a certain amount of code – in our case SP needs a certain base of code loaded simply to enable us to discover whether a forum page has been called or not. If it is NOT a forum page being requested then we load no more. So for non-forum pages the loading is as light as we can make it.

The exception to this, of course, is if items like template tags, short-codes or the recent posts widget are being used to display forum data outside of the forum page. If this is the case then, of course, more code needs to be loaded on every page load to accommodate that.

By the way – I can give you a code edit to stop the show tables query although if we are able to do that as standard still needs some investigation. Although I still do not understand why it should be slow. This seems to be unique to your environment…

If it is NOT a forum page being requested then we load no more.

Great, thank you for the clarification.

I can give you a code edit to stop the show tables query…

Please do, I’m happy to help test this for you!

We are taking various steps to fine tune MySQL, and have yet to identify exactly what in our server environment may be causing the slow queries, so I’m willing to try anything in the meantime to help mitigate the issue.

I found six files with the SHOW TABLES LIKE query, but the only one referencing the sfoptions query that keeps hanging up is:

sp-api-primitives.php:189:  $optionstable = spdb_select(‘var’, “SHOW TABLES LIKE ‘”.SF_PREFIX.”sfoptions'”);

This just seems like too much of a coincidence with the recurrence of errors on the same file that we’re seeing in the SF Toolkit Error Log i mentioned earlier in this thread. Could it have to do something with how I deleted a number of sfmembers and related data from sfmemberships, while keeping them in wp_users and not removing any other sfmember-related metadata? Hope that makes sense.

Thanks again for your time, sorry to be such a pain.

There is no connection between the show tables query and the notices and warnings you were getting. But whether they have anything to do with your data removal I am unsure of yet as I have not investigated that deeply. Probably later today all being well.

As soon as I have code for the options table ‘show’ query I will let you have it.