Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As title. Using the HTTP Parallel Request & Threading Library likely improves performance of the cron job that "visits" all node pages and makes it less likely we'll have time-out errors.
Comments
Comment #1
lolandese CreditAttribution: lolandese commentedIt comes down to using the contrib function httprl_request() instead of drupal_http_request(), but only if the mentioned module is enabled.
Probably we should use it in a non-blocking way, not waiting for the response back. We wonder however if this would still result in the cache being rebuilt for the concerning page? To test. Currently we use drupal_http_request() with the HEAD method. The server MUST NOT return a message-body in the response. It turns out Drupal rebuilds the full page's cache anyway.
Furthermore we have tested the cache warmer only with a limited amount of nodes. We should create dummy content, using Devel_generate, each containing arandon Flickr image (using a random sorted Flickr block based on geo, date or taxonomy) to see if the cache effectively rebuilds on all.
Last but not least, we currently implemented a batch processing if if cache lifetime is substantially bigger than the cron interval (see code below). It seems however that the cache is cleared after cron run in any case for all pages, making our batch processing obsolete. This is unexpected behaviour. Could we change/override this in cron?
Comment #2
lolandese CreditAttribution: lolandese commentedCould we substitute all drupal_http_request(), also in the rest of the code?
Is there another useful fallback besides cURL? See #1272542: fallback code.
Comment #3
lolandese CreditAttribution: lolandese commentedComment #4
lolandese CreditAttribution: lolandese commentedComment #5
lolandese CreditAttribution: lolandese commented