How to speed up the Background Processes?

[Whiskey Bizness]

@mikesound @Ocean West @Ziggs or others in this topic: if you could try it out too it would be appreciated. Thanks!

​Awesome - thanks Charles.  I'll give it a shot!

[Nathan Explosion]

Update this morning:

Pre new file:

~30% on rebuilding posts was done in 24 hours, with 3 cron jobs running at a 1 minute interval each with a sleep in place on 2 of them....so 1 task run every 20 seconds. Started quickly but had slowed to a crawl and was only increasing by .01% on each task run (so .03% in total per minute)

Post new file:

Initially ran with same cron setup for a few hours, and the processing did speed up increasing to ~.04% each task run (so ~1.2% per minute)

Changed the cron jobs to run 1 task per minute only - up this morning, 12 hours after putting in the new file and rebuilding posts is at 61.36%

Monitoring the increase on each task run now and it's increasing at a rate of .03% each minute.

(Note: board has ~2.5 million posts, so .03% is ~8,400 posts a minute)

[Jan Krohn]

For those of you who are experiencing slow task execution please try uploading this file. Simply upload it and then wait for your tasks to run as normal.

applications/core/tasks/ queue.php

Unsupported, use at your own risk, backup, and so on. This is designed to work on 4.0.1. If it helps then we will release it in 4.0.2. Please report your experience here.

​Site is terribly slow after the upgrade. I have uploaded queue.php file replacing the one from 4.0.1 installation and site runs noticeably faster now.

Once all background jobs are done will the forum be as fast as prior to upgrade? v.3.4.7 was extremely fast on my server and my members are mostly complaining about the speed..

It gets slow but as from what I can see it is a bit faster..

[JEFF MACK]

I would just like to ask if the actual site performance will increase after all this background processing is done?

[Jan Krohn]

I would just like to ask if the actual site performance will increase after all this background processing is done?

​Not in our case. It was a bit better but not nearly as good as v3.4.7

Server load was jumping high, A lot of processes were killing the server so I've decided to revert back from the backup.

We're now back on 3.4.7 and members are happy. We'll upgrade at some point, but now it's not the time..

[JEFF MACK]

​Not in our case. It was a bit better but not nearly as good as v3.4.7

Server load was jumping high, A lot of processes were killing the server so I've decided to revert back from the backup.

We're now back on 3.4.7 and members are happy. We'll upgrade at some point, but now it's not the time..

​So you never let the background process complete?  It was hard to tell whether you did or not from your post.

[Jan Krohn]

​So you never let the background process complete?  It was hard to tell whether you did or not from your post.

​Yes I did.. This was an answer to your question..

Not in our case. It was a bit better but not nearly as good as v3.4.7

The site seemed faster after the background processes but not that much...

[Charles]

Some performance improvements will come in 4.0.2 along with quite a lot more in 4.0.3.

[Kirill N]

What exactly does the "Rebuilding post images" process do? It appeared after upgrading to 4.0.1 (I've been running IPS4 since RC3) and after 3 days it's only at 60%. 

[Nathan Explosion]

@Charles - update on my testing of the new file....all done. Considering I had previously seen it take 8 days on one of the RCs, and I gave up after 3 days with 4.0.0, this is a big improvement. I'll be setting things up for another test upgrade for when 4.0.2 comes out.

[Charles]

@Charles - update on my testing of the new file....all done. Considering I had previously seen it take 8 days on one of the RCs, and I gave up after 3 days with 4.0.0, this is a big improvement. I'll be setting things up for another test upgrade for when 4.0.2 comes out.

​Great. I am happy to hear it's speeding things up.

[Starship]

Some performance improvements will come in 4.0.2 along with quite a lot more in 4.0.3.

​This for me will be like a Christmas! Can't wait! Thank you so much!

[LGC]

Is there a solution to this yet? It's been a week since I upgraded and not even a dent in these processes (over a million posts, 12k blog entries, etc).

[Feneroin]

In addition to many fixes from both tickets and the bug tracker, some specifics include:

• Fix for update checker not working
• Search index efficiency improvements
• Guest caching feature can now be used with MySQL (previously required a caching engine like memcached)
• Fix for common problems with queue task locking

Estimated Release of 4.0.7: June 2

[paulcallender@talk21.com]

Is there a solution to this yet? It's been a week since I upgraded and not even a dent in these processes (over a million posts, 12k blog entries, etc).

We have a similar issue - a busy and popular forum with loads of posts and lots of activity. We simply can't afford the forum to be offline for a long time, overnight (say 12 midnight to 8am) is typically the max window we could reasonably have for any planned maintenance. With 1.6 million posts and a rate of approx 100k posts/hour converted, that's 16 hours which is too long.

One option is to archive the posts as they exist now - is archiving a long process in itself (on 3.4.7) - if so how long does it take? Out of the 1.6 million posts in 75,000 topics, a sensivle policy could archive 60% or so, leaving a potential run time for the (main) posts of 6.4 hours. Is it possible, or do they do it already, for the background processes to be scheduled so the active posts are done first, then the archived ones afterwards? So a possible strategy is to keep offline while the main posts are done, then put online and allow the archived posts to be done in due course.

Did they follow up the suggestion to convert the posts most-recent-first order?

I am using 4.0.11 and reading the above, background processing hasn't sped up significantly at all compared to previous versions.

[3DKiwi]

 

We have a similar issue - a busy and popular forum with loads of posts and lots of activity. We simply can't afford the forum to be offline for a long time, overnight (say 12 midnight to 8am) is typically the max window we could reasonably have for any planned maintenance. With 1.6 million posts and a rate of approx 100k posts/hour converted, that's 16 hours which is too long.

One option is to archive the posts as they exist now - is archiving a long process in itself (on 3.4.7) - if so how long does it take? Out of the 1.6 million posts in 75,000 topics, a sensivle policy could archive 60% or so, leaving a potential run time for the (main) posts of 6.4 hours. Is it possible, or do they do it already, for the background processes to be scheduled so the active posts are done first, then the archived ones afterwards? So a possible strategy is to keep offline while the main posts are done, then put online and allow the archived posts to be done in due course.

Did they follow up the suggestion to convert the posts most-recent-first order?

I am using 4.0.11 and reading the above, background processing hasn't sped up significantly at all compared to previous versions.

Have you set a Cron job for background tasks? I did this and things went from turtle speed to warp speed. Very easy to do.

[LaCollision]

Have you set a Cron job for background tasks? I did this and things went from turtle speed to warp speed. Very easy to do.

Is the cron faster than the "execute manually" thingy?

I had the impression that running manually is faster, as the cron job only runs once a minute (the manual script runs each time it finished a cycle).

Thanks,

[AutoItScript]

Cron runs once a minute and works out what it can execute in 45 seconds (it was 30 seconds but got changed in a recent update). That means that for 15 seconds out of every minute no processing is occurring when using cron. On the other hand running manually is running all the time but in smaller chunks and there are all the constant http requests for each cycle. So, it's probably about the same  

The fastest way is to temporarily enable cron and then run a script from ssh that forces it to run constantly rather than each minute:

#!/bin/bash
while :
do
  	/usr/bin/php -d memory_limit=-1 -d max_execution_time=0 /var/www/vhosts/site.com/applications/core/interface/task/task.php xxxxxxxxx
        sleep 1
done

This is safe to run each second or two because if a task is already running it will just exit without doing anything.

You don't have to be offline while the tasks run so as long as your members are aware that content is being fixed it's not a massive problem. Except for search, search indexing runs last (last I checked) so searching is offline for the duration.

[LaCollision]

 Thanks a lot!

[paulcallender@talk21.com]

Cron runs once a minute and works out what it can execute in 45 seconds (it was 30 seconds but got changed in a recent update). That means that for 15 seconds out of every minute no processing is occurring when using cron. On the other hand running manually is running all the time but in smaller chunks and there are all the constant http requests for each cycle. So, it's probably about the same  

The fastest way is to temporarily enable cron and then run a script from ssh that forces it to run constantly rather than each minute:

#!/bin/bash
while :
do
  	/usr/bin/php -d memory_limit=-1 -d max_execution_time=0 /var/www/vhosts/site.com/applications/core/interface/task/task.php xxxxxxxxx
        sleep 1
done

This is safe to run each second or two because if a task is already running it will just exit without doing anything.

You don't have to be offline while the tasks run so as long as your members are aware that content is being fixed it's not a massive problem. Except for search, search indexing runs last (last I checked) so searching is offline for the duration.

I am running the default CRON jobs but haven't scripted it to run more frequently than 1 minute intervals. Looking at "top" (command) in Telnet-SSH session shows that mysqld is sitting on the clock for most of the time, so I don't think there's massive opportunities to improve it anyway.

Highlighted in red - I don't know if it happens for others, but we have just introduced attachments in posts for our members, so many of the threads which have pics, are hosted by us instead of eg photobucket etc. During the background processes running these pictures didn't appear, not even a box with X or anytihng, just a blank space where they were. This obviously makes some threads incoherent, and it would be impossible to explain in each thread, to every member, that a background process is being run and they'll reappear. If it were possible overnight it would be okay.......but a 24h+ period like this? For me, that's a dealbreaker unless there's some kind of golden egg in v4 which makes it a million times better than v3.

 

[media]

On Tuesday, April 07, 2015 9:09:37, bfarber said:

You can set up the cron job per the instructions in the ACP, and you can run the background processes via the ACP manually if you choose.  We have been testing a command line script that effectively does the same thing as the ACP "run background processes manually" command but it is not ready to be distributed - it is still undergoing initial testing, and I am unsure when/if it will be released.

Is this available right now???? Or still in development stage???
Thanks

[bfarber]

39 minutes ago, media said:

Is this available right now???? Or still in development stage???
Thanks

There was no point to it because setting up the cron task now effectively does what the command line script was doing.

[Shariq Ansari]

Just chiming in to confirm that it's definitely slower than I think it both should & could be; IPB 3.4.X seemed to perform similar tasks in half the time... this is on 4.0.13... 

[media]

If I started the background task from ACP, can I stop it and continue running from cronjob????

If the answer yes, please let me know HOW?
Thank you so much

[Rhett]

3 hours ago, media said:

If I started the background task from ACP, can I stop it and continue running from cronjob????

If the answer yes, please let me know HOW?
Thank you so much

Yes just select the cron option and add it on your server/hosting etc.