BobRay / RefreshCache

Refreshes each page in the site cache by requesting it with cURL
https://bobsguides.com/refreshcache-tutorial
5 stars 1 forks source link

RefreshCache stalling #1

Closed hexcollective closed 5 years ago

hexcollective commented 10 years ago

Hi, I'm running MODx 2.3.1 + latest RefreshCache on PHP 5.3 (FastCGI) + CentOS -> RefreshCache is unable to complete it's operation stalling between 25% - 45% of the process.

BobRay commented 10 years ago

Did you try setting the refreshcache_curl_delay property? Try 1 or 2 (if >= 1, it's the delay in seconds between requests).

hexcollective commented 10 years ago

Thanks Bob, in all cases, with 0, 1 or 2 it stalls.

hexcollective commented 10 years ago

Tested in latest Chrome, Firefox and Safari on Mac > Mavericks. Tested refreshcache_ajax_delay 200 + 900 / refreshcache_curl_delay 0, 1 & 2. So far Safari has performed the best with 76.8% complete. If there a way to run this from Cron?

BobRay commented 10 years ago

I wonder if you're running into the typical PHP 30 second execution time limit. The RC code sets it to unlimited, but many servers won't honor that.

You might try adding this as the first line of the delay() function in the class file: set_time_limit(0);

That might reset the time limit for every iteration.

In order to run it from a Cron job, you'd have to add code to instantiate MODX at the top of the snippet. The code for that is here: http://bobsguides.com/blog.html/2013/07/13/using-modx-outside-of-modx/

You'd want to make sure that miscreants couldn't run the snippet repeatedly to slow down your site.

hexcollective commented 10 years ago

Thanks Bob, looks this may be the issue:

Premature end of script headers: index.php, referer: .../manager/?a=84 mod_fcgid: read data timeout in 45 seconds, referer: .../manager/?a=84

Adding these 2 lines to .htaccess resolved the issue for a site a with a smaller number of resources:

php_value max_execution_time 259200 php_value memory_limit 300M

However for another site with approx 300 resources - it stalls with the above readout in error logs.

BobRay commented 10 years ago

Did you try my suggestion above (adding set_time_limit(0) inside the loop)? That should reset the clock on every request and you could drop max_execution time to, say, 200. BTW, if PHP is running in safe_mode, this will have no effect.

Another thought -- maybe the host is throttling you at some point due to the many requests in a short time.

hexcollective commented 10 years ago

Hi Bob,

I added this as such to install.class.php:

public function delay($sec) {
set_time_limit(0);

Is that right? If so, it's had no impact on the larger site (300 resources).

BobRay commented 10 years ago

Yes. Possibly your host has PHP set to ignore all calls to set_time_limit(). In that case, the only solution would be to run it from the command line, either directly, or from a cron job. The code would have to be modified to instantiate $modx. I don't have time to look into it right now, but will try to get to it.

hexcollective commented 10 years ago

Hi Bob, thanks very much for you help. I'd certainly be interested in a version of this component run from Cron and would be happy to help fund that if you're interested.

BobRay commented 9 years ago

That would certainly move it up on the priority list. ;)

Contact me through the contact page at Bob's Guides if you're still interested.