100x performance hit due to not rewriting fq to q.alt [#1429218]

We saw some serious performance issues with a customer using the 6.x branch - possibly the same bug is present in 7.x.

see: http://www.derivante.com/2009/04/27/100x-increase-in-solr-performance-an...

In apachesolr.module in 7.x we handle this problem with the following code:

  if (strlen($keys) == 0 && ($filters = $query->getFilters())) {
    // Move the fq params to q.alt for better performance. Only suitable
    // when using dismax or edismax, so we keep this out of the query class itself
    // for now.
    $qalt = array();
    foreach ($filters as $delta => $filter) {
      // Move the fq param if it has no local params and is not negative.
      if (!$filter['#exclude'] && !$filter['#local']) {
        $qalt[] = '(' . $query->makeFilterQuery($filter) . ')';
        $query->removeFilter($filter['#name'], $filter['#value'], $filter['#exclude']);
      }
    }
    if ($qalt) {
      $query->addParam('q.alt', implode(' ', $qalt));
    }
  }

There is similar code in 6.x-1.x

Comments

Comment #1

pwolanin commented 5 February 2012 at 15:57

Title:

100x performance hit due to not rewritign fq to q.alt

» 100x performance hit due to not rewriting fq to q.alt

Comment #2

pwolanin commented 5 February 2012 at 15:58

Obviously if you are using the standard query parser you can do the same thing by setting the q param, as described in the blog post above.

Comment #3

rjbrown99 commented 17 February 2012 at 23:19

pwolanin - Can you clarify where you are applying this logic in the module? IE - what function in apachesolr.module? apachesolr_views_views_post_execute() perhaps?