If you are having problems posting in the relevant areas for your software, please see this topic.

Telephone Sales and Support Status

Due to the Memorial Day Holiday in the United States, our telephone services will be closed on Monday May 27th, 2019. This includes both the Sales and Support lines. Service will resume again during normal business hours on Tuesday May 28th, 2019.

Long waiting times for posting

Mon 16th Oct '17, 12:09pm

We have this problem since quite a while.
It appears that users with older accounts, 5000+ posts, 500+ photos, have long waiting time when they writing posts. Even up to 2 minuts.
We made a test, and I created for this user new account, and he was able to write in 2 seconds ('Waiting..' at the top was gone in 2 seconds).
Any idea why this happens?

Comment

Yes if you have a table prefix you will need to add that into the queries.

It works much faster for me. I will wait for my '2minutes' user feedback but I think this was the problem.

I was doing optimization and repair, but I did not know I have to delete cache, cacheevent and searchlog.
How often should I repet those commends?
Should I run other maintenance commends on DB as well?

Comment

It works much faster for me. I will wait for my '2minutes' user feedback but I think this was the problem.

I was doing optimization and repair, but I did not know I have to delete cache, cacheevent and searchlog.
How often should I repet those commends?
Should I run other maintenance commends on DB as well?

At the moment run them whenever the site appears to slow down. Once a week should be ok unless you have masses of traffic, but more often will not hurt if you can be bothered. You can do it in the admincp if you give yourself query running permissions in the core config file.

The issue itself should be fixed in 5.3.4 - first public alpha of which, by coincidence, has just been released.

Comment

At the moment run them whenever the site appears to slow down. Once a week should be ok unless you have masses of traffic, but more often will not hurt if you can be bothered. You can do it in the admincp if you give yourself query running permissions in the core config file.

The issue itself should be fixed in 5.3.4 - first public alpha of which, by coincidence, has just been released.

Will do, thanks.

Well, it is very fast now.
It was very frustrating for lots of people on my forum...After 18 months DB was 3.1GB, and now went down to 771MB after your suggested comments. Shocking.

I decided to skip 5.3.3, good to hear 5.3.4 will have this implemented.

Comment

I decided to skip 5.3.3, good to hear 5.3.4 will have this implemented.

I was experiencing the same issues as you while using 5.3.2. The issue was actually resolved or didn't rear its nasty head in 5.3.3. I see it really doesn't matter now though since Alpha versions of 5.3.4 are now released, and it is officially addressed.

Optimization and Repair will not do much to improve performance of your site.

In MySQL, Optimization means delete content that is already marked for deletion. If you haven't mass deleted topics or attachments recently, there isn't any real reason to run this. Doing so won't gain anything.

Repair should only be run if a table it marked as "Crashed and should be repaired". If you're using INNODB, this actually doesn't do much of anything. With MyISAM, your site will probably be down if tables need repairing. Running a repair on tables that don't need it can cause those tables to crash, ironically.

Comment

Optimization and Repair will not do much to improve performance of your site.

In MySQL, Optimization means delete content that is already marked for deletion. If you haven't mass deleted topics or attachments recently, there isn't any real reason to run this. Doing so won't gain anything.

Repair should only be run if a table it marked as "Crashed and should be repaired". If you're using INNODB, this actually doesn't do much of anything. With MyISAM, your site will probably be down if tables need repairing. Running a repair on tables that don't need it can cause those tables to crash, ironically.

Thank you for information Wayne.

I was using commends from drop menu in adminmyphp (at the bottom of 'Structure'). Check all -> With selected: Optimize Table. I am not sure if I used repair there. I have couple engines on server but: "InnoDB is the default storage engine on this MySQL server"
It did not crash yet so hopefully everything is fine. When I use check selected table everything is 'OK'.

I know there is optimize/repair table in admin panel and this I have used many times...

Comment

I was using commends from drop menu in adminmyphp (at the bottom of 'Structure'). Check all -> With selected: Optimize Table. I am not sure if I used repair there. I have couple engines on server but: "InnoDB is the default storage engine on this MySQL server"
It did not crash yet so hopefully everything is fine. When I use check selected table everything is 'OK'.

I know there is optimize/repair table in admin panel and this I have used many times...

As Wayne has indicated, repair and optimize are not 'routine maintenance' commands and should never be run unless there is a specific reason to do so.

We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.

By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also consent to the transfer of your data to our servers in the United States, where data protection laws may be different from those in your country.