Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A74A09ED9 for ; Fri, 9 Mar 2012 02:46:22 +0000 (UTC) Received: (qmail 22420 invoked by uid 500); 9 Mar 2012 02:46:19 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 22236 invoked by uid 500); 9 Mar 2012 02:46:19 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 22207 invoked by uid 99); 9 Mar 2012 02:46:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Mar 2012 02:46:18 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Mar 2012 02:46:17 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 38E7A104D2 for ; Fri, 9 Mar 2012 02:45:57 +0000 (UTC) Date: Fri, 9 Mar 2012 02:45:57 +0000 (UTC) From: "Russell Black (Updated) (JIRA)" To: dev@lucene.apache.org Message-ID: <2076280617.42073.1331261157234.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <195928260.41939.1331256837659.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Updated] (SOLR-3222) Pull optimal cache warming queries from a warm solr instance MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/SOLR-3222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3222: -------------------------------- Description: Ever wondered what queries to use to prime your cache? This patch allows you to query a warm running instance for a list of warming queries. The list is generated from the server's caches, meaning you get back an optimal set of queries. The set is optimal to the extent that the caches are optimized. The queries are returned in a format that can be consumed by the {code:xml}{code} section of {{solrconfig.xml}}. One can use this feature to generate a static set of good warming queries to place in {{solrconfig.xml}} under {code:xml}{code} It can even be used in a dynamic fashion like this: {code:xml} {code} which can work well in certain distributed load-balanced architectures, although in production it would be wise to add an {{}} element to the include in the event that the host is down. I implemented this by introducing a new request handler: {code:xml} {code} The request handler pulls a configurable number of "top" keys from the {{filterCache}},{{fieldValueCache}}, and {{queryResultCache}}. For each key, it constructs a query that will cause that key to be placed in the associated cache. The list of constructed queries are then returned in the response. Patch to follow. was: Ever wondered what queries to use to prime your cache? This patch allows you to query a warm running instance for a list of warming queries. The list is generated from the server's caches, meaning you get back an optimal set of queries. The set is optimal to the extent that the caches are optimized. The queries are returned in a format that can be consumed by the {code:xml}{code} section of {{solrconfig.xml}}. One can use this feature to generate a static set of good warming queries to place in {{solrconfig.xml}} under {code:xml}{code} It can even be used in a dynamic faction like this: {code:xml} {code} which can work well in certain distributed load-balanced architectures, although in production it would be wise to add an {{}} element to the include in the event that the host is down. I implemented this by introducing a new request handler: {code:xml} {code} The request handler pulls a configurable number of "top" keys from the {{filterCache}},{{fieldValueCache}}, and {{queryResultCache}}. For each key, it constructs a query that will cause that key to be placed in the associated cache. The list of constructed queries are then returned in the response. Patch to follow. > Pull optimal cache warming queries from a warm solr instance > ------------------------------------------------------------ > > Key: SOLR-3222 > URL: https://issues.apache.org/jira/browse/SOLR-3222 > Project: Solr > Issue Type: New Feature > Components: search > Affects Versions: 3.5, 4.0 > Reporter: Russell Black > Labels: patch, performance > > Ever wondered what queries to use to prime your cache? This patch allows you to query a warm running instance for a list of warming queries. The list is generated from the server's caches, meaning you get back an optimal set of queries. The set is optimal to the extent that the caches are optimized. The queries are returned in a format that can be consumed by the {code:xml}{code} section of {{solrconfig.xml}}. > One can use this feature to generate a static set of good warming queries to place in {{solrconfig.xml}} under {code:xml}{code} > It can even be used in a dynamic fashion like this: > {code:xml} > > > > {code} > which can work well in certain distributed load-balanced architectures, although in production it would be wise to add an {{}} element to the include in the event that the host is down. > I implemented this by introducing a new request handler: > {code:xml} > > {code} > The request handler pulls a configurable number of "top" keys from the {{filterCache}},{{fieldValueCache}}, and {{queryResultCache}}. For each key, it constructs a query that will cause that key to be placed in the associated cache. The list of constructed queries are then returned in the response. > Patch to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org