happy to reply: it’s 5.1.3 / build 8972. On a sidenote: we just saw that the sfmembers table amounts to a size of almost 35mb (with an overhaed of 21mb)! Is that normal?

I just logged in again. It redirects to the news section upon login. Clicking the forum tab it just sat there for several seconds before even building a browser scroll bar. Definitely a problem there.

Here’s a screen grab.

http://youtu.be/sna1tLn6xNE

Dosenben said
happy to reply: it’s 5.1.3 / build 8972. On a sidenote: we just saw that the sfmembers table amounts to a size of almost 35mb (with an overhaed of 21mb)! Is that normal?

Er. No. I wouldn’t think so! Not for your membership size.

You should have one row for every member. In fact – it should have the same row count as the WP users table. That alone could account for your issues as the sfmembers table will not be accessed for a guest of course. nd any overhead needs to be dealt with.

So – what is the row count of both tables? Any idea what might be wrong as this is not something we have encountered before to my knowledge…

361 rows on both counts – wp_users and wp_sfmembers. On a database test installation (same server, other db); reducing the member count to 1 (deleting the 360 others) did nothing for the load time, the imported content stayed the same.

On another note: The previous server was taken out of action by attacks; we had some serious problems with modified .htaccess files that were replicated by some weird script. WP didn’t seem to be directly affected though.

Weird, really. To make things easier – if you would be so kind to take a direct look; would you prefer the account data for the mySQL – Database (partly german) or the whole shebang in exported form?

Yellow Swordfish said

Dosenben said
happy to reply: it’s 5.1.3 / build 8972. On a sidenote: we just saw that the sfmembers table amounts to a size of almost 35mb (with an overhaed of 21mb)! Is that normal?

Er. No. I wouldn’t think so! Not for your membership size.

You should have one row for every member. In fact – it should have the same row count as the WP users table. That alone could account for your issues as the sfmembers table will not be accessed for a guest of course. nd any overhead needs to be dealt with.

So – what is the row count of both tables? Any idea what might be wrong as this is not something we have encountered before to my knowledge…

I’m thinking Spambot Registrations!

In WordPress > Users > How many registered but unverified users do you have.

361; as in the wp_users and wp_sfmembers table…

I might be able to explain this although not necessarily effect a cure! The bad news is that it probably comes down to your rather large 297 forum records. I will explain..

You will have in your SP somewhere between 45 and 55 permission settings depending on what SP plugins you have installed. These are mapped to individual forums with their appropriate on/off settings. So there is one set per forum. For efficiency (and yes I really do mean that!) this mapping is cached in the sfmembers table. This means that is far quicker, by a very long way, to check any permission for the current user against any forum.

But…. say 50 permission records multiplied by 297 forums held in a php serialised array is an awful lot of data. And it probably accounts for the size of your sfmembers table. I am surprised by the size of your table but I reckon this is what is behind it.

If you then look at this the other way it has to be said that this will still be more efficient than building that complex map every time the page is run.

The first thing to do is optimise that table. I would also recommend you grab as much php memory as you can muster. And I will put n my thinking cap…

Hello Andy,

you’re definitly far more at home in the wp tables than i can hope to be – the weird thing is that the guest user seems the same content, but it loads faster by miles – although he’s of course on a general “read only” access. I’ll optimise the tables and send you the access to the mySQL admin (by mail); if that’s alright with you.

thanks for your kind support to the both of you, best regards,

Ben

Andy, thanks for that DB info.

It’s very interesting, and i learned something else today. I’m not much of a database admin, other than import or export that’s about it.

This is a great friendly forum.

Dosenben said
you’re definitly far more at home in the wp tables than i can hope to be – the weird thing is that the guest user seems the same content, but it loads faster by miles – although he’s of course on a general “read only” access. I’ll optimise the tables and send you the access to the mySQL admin (by mail); if that’s alright with you.

Received the credentials but the tables have not yet been optimised. I would feel more comfortable if you do that to be honest. Maybe perform a check table beforehand.

You really need to get the Db optimised first and then try running the forum again to see if this makes any difference.

FidoSysop said
Andy, thanks for that DB info.

It’s very interesting, and i learned something else today. I’m not much of a database admin, other than import or export that’s about it.

This is a great friendly forum.

Thanks Sometimes it is hard to remember all of the wrinkles however!

Hey Andy;

finally we got around to optimizing the tables! Sorry for the delay. There’s a noticeable improvement in the subforums; nevertheless the front page still loads painfully slow. If i could trouble you to take a look now (after we demolished out db ); maybe you can see something we’d never notice.

best regards!

Ben

I don’t believe there are any issues as such. I think this is all down to the caching which, of course, for 99.9% of users is a performance boost!

We will talk it over here to see if we can come up with anything that might help…