Got a strange problem driving me nuts:

When I post a news story on my site it takes about 20 seconds for the splash screen 'thank you for your submission' to load. The stories get through so it still actually works, but the delay is quite annoying. It just started today.

The thing that has me confused is that the rest of my site is running really fast so I don't think its a bandwidth problem, and locally I've tested across 2 separate internet connections. I've also tried restarting MySQL and Apache, no difference. Editing a story (resubmitting) is quite fast.

The only thing I did differently today was to click 'repair tables' in MyPHPAdmin and 'maintain tables' in the News module itself. No errors or problems were reported, but could this potentially slow a table down?

Anyone got a suggestion?

Since just done that with CBB tables also my self, here some possibilities:

1st) MySql has heavy indexing and is storing long terms of various characters also, these do not get indexed well, they should be stored or retrieved from data alone. So if you see lots of index keys with permissions, an id is normally all that is required to find that same data in the table it has been asked to look at.
2nd) When calls are made having spaces in the PHP calling it for instance.

XOOPS_URL . $SOMETHING . ( ( ( WHERE ) ) ) {
}

That is very bad PHP and people are learning from PHP’s site its self, which also advises spaces, yet only as reference…we are talking processor strings….so should look like this


XOOPS_URL.$SOMETHING.((( WHERE ))){}


That speeds up all processes and within Wizanda all is done like this….haven’t done News yet as not using it.

So have a look at the submit page of PHP and if it is looks like swiss cheese, you know that PHP will be also causing a big delay in asking Mysql.

Then MySql needs to be 1 point of origin and all stem from that below it like a flow chart….
So primary is id, next indexes linking all items…. next one finishes ids….. so all requires id’s are supplied in flow chart style first and permission are found at the end in data, if everything is else is provided so at the end permission and data is quick, if any id is missing it will still be slow.
A big one is also including a copy of approved in many of the modules index keys, so as well as including say topic_id in post_id….we also can include if topic_id is approved in one index key linked, with as many items linked in sequential order you know it will ask for….
Reason is that primary can interlink with anything indexing first. yet only as a means to find it quicker for data, not to store it all.
If to much is in index and the percentage of data is above that of the actual data, that to me is very bad……all index keys need to be light as possible, and the data can be found even in a large site, else the overhead in the indexes stops it find it all.

Hope that helps.

do you have a lot of notifications for news module?
i had a same problem. at this time just have to disable notification for news.
i found the link:
here

Sure do. Thanks heaps, I would never have figured that out myself :) I disabled notifications and news story submissions are now blazingly fast!

I think I'm going to clear out the site's notifications entirely (maybe run adapt that nice script you posted with Herve's xoopscare module) and ask my users to reset them if they still want them. I have a lot of users that don't log in but whose accounts still generating these things.

I can't imagine how xoops.org avoids collapsing into a black hole of notifications :)

Thanks again. "Fix of the week" :)