--
View this message in context:
http://lucene.472066.n3.nabble.com/Feature-skipping-caches-and-info-about-cache-use-tp3020325p3028894.html
Sent from the Solr - User mailing list archive at Nabble.com.
sen
> To: solr-user@lucene.apache.org
> Sent: Fri, June 3, 2011 5:58:43 PM
> Subject: RE: Feature: skipping caches and info about cache use
>
> Why, I'm just wondering?
>
> For a case where you know the next query would not be possible to be
> already in the cache
On Fri, Jun 3, 2011 at 1:02 PM, Otis Gospodnetic
wrote:
> Is it just me, or would others like things like:
> * The ability to tell Solr (by passing some URL param?) to skip one or more of
> its caches and get data from the index
Yeah, we've needed this for a long time, and I believe there's a JIR
ponse times)?
-Original Message-
From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com]
Sent: Friday, June 03, 2011 10:02 AM
To: solr-user@lucene.apache.org
Subject: Feature: skipping caches and info about cache use
Hi,
Is it just me, or would others like things like:
* The ability to
Hi,
Is it just me, or would others like things like:
* The ability to tell Solr (by passing some URL param?) to skip one or more of
its caches and get data from the index
* An additional attrib in the Solr response that shows whether the query came
from the cache or not
* Maybe something else a
cheers,
-Mike
- Original Message
From: Mike Klaas <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Tuesday, December 4, 2007 2:33:24 PM
Subject: Re: Cache use
On 4-Dec-07, at 8:43 AM, Evgeniy Strokin wrote:
Hello,...
we have 110M records index under Solr. Some queries ta
Message-
From: sfox [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 06, 2007 1:24 PM
To: solr-user@lucene.apache.org
Subject: Re: Cache use
One possible explanation is that the OS's native file system caching is
being successful at keeping these files mostly in RAM most of the time.
One possible explanation is that the OS's native file system caching is
being successful at keeping these files mostly in RAM most of the time.
And so the performance benefits of 'forcing' the files into RAM by
using tmpfs aren't significant.
So the slowness of the queries is the result of be
No one has a suggestion? I must be missing something because as I
understand it from Dennis' email, all of queries are very quick
(cached type response times) whereas mine are not. I can clearly see
time differences between queries that are cached (things that have
been auto warmed) and que
Thanks for the suggestion, Dennis. I decided to implement this as you
described on my collection of about 400,000 documents, but I did not
receive the results I expected.
Prior to putting the indexes on a tmpfs, I did a bit of benchmarking and
found that it usually takes a little under two sec
))...
- Original Message
From: Dennis Kubes <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Tuesday, December 4, 2007 12:00:55 PM
Subject: Re: Cache use
One way to do this if you are running on linux is to create a tempfs
(which is ram) and then mount the filesystem in the ram. The
ould cache all data of this set. If after I run just TOWN:L*
, which is subset of the first query, it still takes time to get the result
back, as if it's not cached..
- Original Message
From: Mike Klaas <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Tuesday, Dece
On 4-Dec-07, at 8:43 AM, Evgeniy Strokin wrote:
Hello,...
we have 110M records index under Solr. Some queries takes a while,
but we need sub-second results. I guess the only solution is cache
(something else?)...
We use standard LRUCache. In docs it says (as far as I understood)
that it lo
The first step is to look at what searches are taking too long, and
see if there is a way to structure them so they don't take as long.
The whole index doesn't have to be in memory to get good search
performance, but 100M documents on a single server is big. We are
working on distributed search (
One way to do this if you are running on linux is to create a tempfs
(which is ram) and then mount the filesystem in the ram. Then your
index acts normally to the application but is essentially served from
Ram. This is how we server the Nutch lucene indexes on our web search
engine (www.visvo
Hello,...
we have 110M records index under Solr. Some queries takes a while, but we need
sub-second results. I guess the only solution is cache (something else?)...
We use standard LRUCache. In docs it says (as far as I understood) that it
loads view of index in to memory and next time works with
16 matches
Mail list logo
