Hiya,

I currently have a site which is a photo gallery where a photo gallery can have up to a couple thousand referenced photos. Now for each photo view, I have a custom pager (using the custom pagers module) that utilizes a view to provide a listing of the photos. However, whenever I load the photo and the pager, boost_views_pre_render() kicks in and runs node_load on all of the photos to get their type to establish a relationship. Doing this approach seems quite excessive to set a relationship as the node_load operation can be expensive and in my scenario, it ends up running nearly 5k queries on a photo page load for an anonymous user; in comparison, an authenticated user gets up to 120 queries running on the page. I'm not sure if the best approach to this would be to (in my custom module) 'shut off' '_boost_cache_this' and turn it back on so the page itself can get cached or if some other modification needs to occur so that the operation on whether or not a node was loaded can be improved. I'd be more than willing to submit a patch to boost (if that is the best approach) pending some guidance from the maintainers :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BTMash’s picture

It seems like the simple solution (atleast what I have right now) is in my custom module, I have the following code:

/**
 * Implementation of hook_views_pre_execute().
 * Run before boost and its views portion executesexecutes
 */
function custom_module_views_pre_execute(&$view) {
  if ($view->name == 'photo_gallery_content' && module_exists('boost')) {
    global $_boost_cache_this, $_boost_cache_this_backup;
    $_boost_cache_this_backup = $_boost_cache_this;
    $_boost_cache_this = FALSE;
  }
}

/**
 * Implementation of hook_views_post_render().
 * Run after boost executes
 */
function custom_module_views_post_render(&$view) {
  if ($view->name == 'photo_gallery_content' && module_exists('boost')) {
    global $_boost_relationships, $_boost_cache_this, $_boost_cache_this_backup;
    $_boost_cache_this = $_boost_cache_this_backup;
    if ($_boost_cache_this) {
      $nids = array();
      foreach ($view->result as $item) {
        $nids[] = $item->nid;
      }
      $result = db_query("SELECT nid, type FROM {node} WHERE nid IN (". implode(', ', $nids) .")");
      while($node = db_fetch_object($result)) {
        $GLOBALS['_boost_relationships'][] = array('child_page_callback' => 'node', 'child_page_type' => $node->type, 'child_page_id' => $item->nid);
      }
    }
  }
}

This seems to allow the relationships to exist with a view while keeping the performance relatively fast. I tried this on a page with about 1k nodes in the custom pager and things seem to work just fine (the query takes between 6 and 10 milliseconds). Even separated out on each query, each one should be really fast (though it would add up). What I'm wondering is if there is a way to make what I wrote even most db-agnostic (so it can be queried against mongodb and the like without issues) so that a portion of what I wrote makes its way into boost instead of being in a custom table.

I'm attaching a variant of what I wrote as a patch to the boost module to get this going.

BTMash’s picture

Argh...can't believe I screwed up a simple patch.

Try #2

killua99’s picture

This patch affect views page loaded through ajax? I disable caching when a page present ?page=1 etc ... but I'll love if I can caching that page too. My ajax return some kind of error.

BTMash’s picture

Hmm, it shouldn't have an effect on things loaded through ajax since nothing it output to the screen. Which patch did you try?

killua99’s picture

Neither yet, I just asking. My ajax kick some kind of error, about json compilation, kind of weird actually. Monday I'll put some extra of my code error. Thanks for the early response, appreciate it.

BTMash’s picture

Status: Active » Fixed

I'm marking off this issue as 'fixed'. It *seems* like this has been resolved in the dev branch of boost. I cannot verify if that works or not but from what I see in the code, node_load operations are no longer occurring which is a good sign :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.