I tried using SolrMeter but for some reason it does not detect my url and
throws solr server exception
Sent from my iPhone
> On 21-Jul-2015, at 10:58 am, Alessandro Benedetti
> wrote:
>
> SolrMeter mate,
>
> http://code.google.com/p/solrmeter/
>
> Take a look, it will help you a lot !
>
>
SolrMeter mate,
http://code.google.com/p/solrmeter/
Take a look, it will help you a lot !
Cheers
2015-07-21 16:49 GMT+01:00 Nagasharath :
> Any recommended tool to test the query performance would be of great help.
>
> Thanks
>
--
--
Benedetti Alessandro
Visiting c
:34 PM
To: solr-user@lucene.apache.org
Subject: Re: Query Performance
Actually I have to rewrite my question:
Query 1:
q=*:*&rows=row_count&sort=id asc&start=X
and
Query2:
q={X TO *}&rows=row_count&sort=id asc&start=0
2013/7/29 Jack Krupansky
The second query excludes do
Actually I have to rewrite my question:
Query 1:
q=*:*&rows=row_count&sort=id asc&start=X
and
Query2:
q={X TO *}&rows=row_count&sort=id asc&start=0
2013/7/29 Jack Krupansky
> The second query excludes documents matched by [* TO X], while the first
> query matches all documents.
>
> Relati
The second query excludes documents matched by [* TO X], while the first
query matches all documents.
Relative performance will depend on relative match count and the sort time
on the matched documents. Sorting will likely be the dominant factor - for
equal number of documents. So, it depends
Charles,
Grab Solr nightly build and try that. Should be much faster.
n.b. you don't need 10 in your
config
any more. (although this looks like a config from your master, not slave, if
you
are using that sort of setup)
Otis
Sematext :: http://sematext.com/ :: Solr - Lucene - Nu
I'll guess that if you have wildcards with more letters in front of
the * your queries are fine, right? The underlying problem is that
Solr has to enumerate every term in your title field that starts with
'h' to see if they match your pattern.
You can require more letters at the beginning. You cou
No Wease,
We got the performance improvement after doing the following stuff
--> Reduced the merge factor from 10 to 3.
--> Auto-warming queries as I mentioned in my initial thread.
Thanks,
Johnny
--
View this message in context:
http://lucene.472066.n3.nabble.com/Query-performance-very-s
Johnny:
Are you still looking for help?
Wease
-
NOT always nice. When are we getting better releases?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Query-performance-very-slow-even-after-autowarming-tp2010384p2542789.html
Sent from the Solr - User mailing list archi
Hmmm. "find evicted docs"? If you mean find out how many docs are deleted,
look
on the admin "schema browser" page and the difference between MaxDoc and
NumDocs
is the number of deleted documents.
You say "for some queries the QTime is more than 8 secs". What happens if
you
re-run that query a bit
1) Thanks for this update. I have to use 'WhiteSpaceTokenizer'
2) I have to suggest the whole query itself (Say name or title)
3) Could you please let me know if there is a way to find the evicted docs?
4) Yes, we are seeing improvement in the response time if we optimize. But
still for some queri
A couple of observations:
1> your regex at query time is interesting. You're using KeywordTokenizer,
so input of
"search me" becomes "searchme" before it goes through the parser. Is
this your intent?
2> Why are you using EdgeNGrams for auto suggest? The TermsComponent is
an easier, more e
Hi Chris,
Thanks for looking into it.
Here is the sample query.
http://localhost:8080/solr/core0/select/?qt=autosuggest&q=a
I am using a request handler with a name autosuggest with the following
configuration.
json
name,score
scor
: I made the field that is indexed with EdgeNGramFilterFactory as default
: search field. All my query responses are very slow, some of them taking more
: than 10seconds to respond.
based on the info you've given, there's dozens of posisble reasons why you
might see slow queries -- it's hard to
Alexey,
1) I am using EdgeNGramFilter only in index analyzer alone.
2) Sometimes even multiple characters also creating problems,
What i told was an example for a performance problem, And moreover I am
trying out the autowarming and sometime it is not working ideally [100%
guaranteed performan
* Do you use EdgeNGramFilter in index analyzer only? Or you also use
it on query side as well?
* What if you create additional field first_letter (string) and put
first character/characters (multivalued?) there in your external
processing code. And then during search you can filter all documents
t
: Does the following query has any performance impact over
: the second query?
: +title:lucene +(title:lucene -name:sid)
: +(title:lucene -name:sid)
the second should in theory be faster then the first just because of
reduced number of comparisons needed -- but wether or not yo
On Tue, Mar 10, 2009 at 11:37 AM, Sammy Yu wrote:
> Hi guys,
> I'm trying to limit the size of my index and one of the things I
> have done is to not populate certain fields when the majority of the
> document have that value. For example, if most of my documents in my
> index have a field col
: Just to clarify - we do not optimize on the slaves at all. We only optimize
: on the master.
that doesn't change anything about hte comments that i made before. it
*really* wouldn't make sense to optimize on a slave right before pulling a
new snapshot, but it still doesn't make any more sens
Just to clarify - we do not optimize on the slaves at all. We only optimize
on the master.
hossman wrote:
>
>
> : We do optimize the index before updates but we get tehse performance
> issues
> : even when we pull an empty snapshot. Thus even when our update is tiny,
> the
> : performance issue
Just to calrify - we do not optimize on teh slaves at all. We only optimize
on the master.
hossman wrote:
>
>
> : We do optimize the index before updates but we get tehse performance
> issues
> : even when we pull an empty snapshot. Thus even when our update is tiny,
> the
> : performance issue
Just to calrify - we do not optimize on the slaves at all. We only optimize
on the master.
hossman wrote:
>
>
> : We do optimize the index before updates but we get tehse performance
> issues
> : even when we pull an empty snapshot. Thus even when our update is tiny,
> the
> : performance issue
: We do optimize the index before updates but we get tehse performance issues
: even when we pull an empty snapshot. Thus even when our update is tiny, the
: performance issues still happen.
FWIW: this behavior doesn't make a lot of sense -- optimizing just
before you are about to make updates/a
hatever
> queries are in flight? Try jconsole.
>
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>
>
> - Original Message
>> From: oleg_gnatovskiy
>> To: solr-user@lucene.apache.org
>> Sent: Thursday, January 22, 2009
gt; From: oleg_gnatovskiy
> To: solr-user@lucene.apache.org
> Sent: Thursday, January 22, 2009 2:43:31 PM
> Subject: Re: Query Performance while updating teh index
>
>
> We do optimize the index before updates but we get tehse performance issues
> even when we pull an empty snapshot.
From: oleg_gnatovskiy
>> To: solr-user@lucene.apache.org
>> Sent: Tuesday, January 20, 2009 6:19:46 PM
>> Subject: Re: Query Performance while updating teh index
>>
>>
>> Hello again. It seems that we are still having these problems. Queries
>> take
>
: solr-user@lucene.apache.org
> Sent: Wednesday, January 21, 2009 1:09:21 PM
> Subject: Re: Query Performance while updating teh index
>
>
> What exactly does Solr do when it receives a new Index? How does it keep
> serving while performing the updates? It seems that the part that
From: oleg_gnatovskiy
>> To: solr-user@lucene.apache.org
>> Sent: Tuesday, January 20, 2009 6:19:46 PM
>> Subject: Re: Query Performance while updating teh index
>>
>>
>> Hello again. It seems that we are still having these problems. Queries
>> take
>>
rom: oleg_gnatovskiy
> To: solr-user@lucene.apache.org
> Sent: Tuesday, January 20, 2009 6:19:46 PM
> Subject: Re: Query Performance while updating teh index
>
>
> Hello again. It seems that we are still having these problems. Queries take
> as long as 20 minutes to get back to their avera
Hello again. It seems that we are still having these problems. Queries take
as long as 20 minutes to get back to their average response time after a
large index update, so it doesn't seem like the problem is the 12 second
autowarm time. Are there any more suggestions for things we can try? Taking
;
> -Original Message-
> From: oleg_gnatovskiy [mailto:oleg_gnatovs...@citysearch.com]
> Sent: Friday, December 12, 2008 11:19 AM
> To: solr-user@lucene.apache.org
> Subject: RE: Query Performance while updating teh index
>
>
> The auto warm time is not an issue. We t
eg_gnatovs...@citysearch.com]
Sent: Friday, December 12, 2008 11:19 AM
To: solr-user@lucene.apache.org
Subject: RE: Query Performance while updating teh index
The auto warm time is not an issue. We take the server off the load
balancer
while it is autowarming. It seems that the slowness occurs after
a
I just verified this. The slowness occurs after auto warm is done.
Oleg
--
View this message in context:
http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p20982068.html
Sent from the Solr - User mailing list archive at Nabble.com.
may
> have to set that value in the hundreds, as opposed to tens of thousands.
>
> -Todd Feak
>
> -Original Message-
> From: oleg_gnatovskiy [mailto:oleg_gnatovs...@citysearch.com]
> Sent: Friday, December 12, 2008 10:08 AM
> To: solr-user@lucene.apache.org
>
]
> Sent: Friday, December 12, 2008 10:08 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Query Performance while updating teh index
>
>
> Here's what we have on one of the data slaves for the autowarming.
>
>
>
> --
>
> Dec 12, 2008 8:46:02 AM org.apache
solr-user@lucene.apache.org
Subject: Re: Query Performance while updating teh index
Here's what we have on one of the data slaves for the autowarming.
--
Dec 12, 2008 8:46:02 AM org.apache.solr.search.SolrIndexSearcher warm
INFO: autowarming searc...@3f32ca2b main from searc...@443
Message
> From: oleg_gnatovskiy
> To: solr-user@lucene.apache.org
> Sent: Friday, December 12, 2008 1:07:49 PM
> Subject: Re: Query Performance while updating teh index
>
>
> Here’s what we have on one of the data slaves for the autowarming.
>
>
>
>
Here’s what we have on one of the data slaves for the autowarming.
--
Dec 12, 2008 8:46:02 AM org.apache.solr.search.SolrIndexSearcher warm
INFO: autowarming searc...@3f32ca2b main from searc...@443ad545 main
filterCache{lookups=351993,hits=347055,hitratio=0.98,inserts=8332,eviction
Hey Otis,
Do you think our problem is slow warm time, or too few items that are being
copied?
Oleg
--
View this message in context:
http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p20980523.html
Sent from the Solr - User mailing list archive at Nabble.com.
rom: oleg_gnatovskiy
> To: solr-user@lucene.apache.org
> Sent: Thursday, December 11, 2008 8:43:26 PM
> Subject: RE: Query Performance while updating teh index
>
>
> We are still having this problem. I am wondering if it can be fixed with
> autowarm settings. Is there a reliable for
We are still having this problem. I am wondering if it can be fixed with
autowarm settings. Is there a reliable formula for determining the autowarm
settings?
--
View this message in context:
http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p20968516.html
Sent from the
: How about create a new core, index data, then swap the core? Old core
: is still available to handle queries till new core replaces it.
a new SolrCore shouldn't help in a situation like this ... with
snapshots and commits on a single SolrCore you at least get the benefits
of autowarming and
oe
To: solr-user@lucene.apache.org
Subject: RE: Query Performance while updating teh index
Yes, this is the cache autowarming.
We turned this off and staged separate queries that pre-warm our
standard queries. We are looking at pulling the query server out of the
load balancer during this process; it i
t;>
>> Lance
>>
>> -Original Message-----
>> From: oleg_gnatovskiy [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, November 12, 2008 11:07 AM
>> To: solr-user@lucene.apache.org
>> Subject: Re: Query Performance while updating teh index
>>
>>
the most effective way to give fixed response
> time.
>
> Lance
>
> -Original Message-
> From: oleg_gnatovskiy [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 12, 2008 11:07 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Query Performance while updating
://sematext.com/ -- Lucene - Solr - Nutch
From: oleg_gnatovskiy <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org
Sent: Wednesday, November 12, 2008 2:16:44 PM
Subject: Re: Query Performance while updating teh index
Yonik Seeley wrote:
>
> On
: RE: Query Performance while updating teh index
Yes, this is the cache autowarming.
We turned this off and staged separate queries that pre-warm our
standard queries. We are looking at pulling the query server out of the
load balancer during this process; it is the most effective way to give
fixed
Yonik Seeley wrote:
>
> On Wed, Nov 12, 2008 at 2:06 PM, oleg_gnatovskiy
> <[EMAIL PROTECTED]> wrote:
>> The rsync seems to have nothing to do with slowness, because while the
>> rsync
>> is going on, there isn't any reload occurring, once the files are on the
>> system, it tries a curl request
-
From: oleg_gnatovskiy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2008 11:07 AM
To: solr-user@lucene.apache.org
Subject: Re: Query Performance while updating teh index
The rsync seems to have nothing to do with slowness, because while the rsync
is going on, there isn't any r
On Wed, Nov 12, 2008 at 2:06 PM, oleg_gnatovskiy
<[EMAIL PROTECTED]> wrote:
> The rsync seems to have nothing to do with slowness, because while the rsync
> is going on, there isn't any reload occurring, once the files are on the
> system, it tries a curl request to reload the searcher, which at th
The rsync seems to have nothing to do with slowness, because while the rsync
is going on, there isn’t any reload occurring, once the files are on the
system, it tries a curl request to reload the searcher, which at that point
causes the delays. The file transfer probably has nothing to do with thi
On Tue, Nov 11, 2008 at 9:31 PM, oleg_gnatovskiy
<[EMAIL PROTECTED]> wrote:
> Hello. We have an index with 15 million documents working on a distributed
> environment, with an index distribution setup. While an index on a slave
> server is being updated, query response times become extremely slow (
I'll assume you are using the rsync-based replication, not SOLR-561.
In that case, bwlimit is your friend. You'll have to modify the scripts and
make use of this:
--bwlimit=KBPS
This option allows you to specify a maximum transfer rate in
kilobytes per second. This option i
53 matches
Mail list logo
