the following fields:
Thanks
Christophe
It is slow each time I run it. (I test it from the Solr admin console or
from a JAVA program using the Http client).
I do not get the OOM each time.
Thx
Christophe
Otis Gospodnetic wrote:
Is the sorted query slow only the first time or every time you run it?
You got an OOM? What -Xmx value
arching at the same time: I will do
a stress test to check this.
Thanks
Christophe
christophe wrote:
It is slow each time I run it. (I test it from the Solr admin console
or from a JAVA program using the Http client).
I do not get the OOM each time.
Thx
Christophe
Otis Gospodnetic wrot
Will do so. Thanks.
Are there any metrics on how to compute memory requirements (based on
doc average size, number of sorted fields, number of indexed documents +
number of new document / day) ?
Thanks
Christophe
Mark Miller wrote:
You need to setup a warming query that sorts so that the
When I start indexing new documents, searches are taking long time
again: is the sort cache flushed when new documents are indexed ?
Thanks
Christophe
Mark Miller wrote:
You need to setup a warming query that sorts so that the initial long
query is done behind the scenes. Users first query
new documents are created.
C.
Mark Miller wrote:
christophe wrote:
When I start indexing new documents, searches are taking long time
again: is the sort cache flushed when new documents are indexed ?
When you commit, a new Reader will be opened (or reopened) so that the
freshly added docs
l user requests served by this
reader ? How does that scale if I have many concurrent users ?
C.
Norberto Meijome wrote:
On Mon, 20 Oct 2008 16:28:23 +0300
christophe <[EMAIL PROTECTED]> wrote:
Hum. this mean I have to wait before I index new documents and avoid
indexing when the
field with less
different values than a timestamp ? I'm looking for some details on how
the cache is populated on the first query. Also, for the code insiders
;-), would that be difficult to change this caching mechanism to allow
update and reuse of an existing cache ?
Thanks for your help
Christop
ave a correct
response time, even for the first query. I still want to check with 10M
and more documents.
Once my index is fully loaded, I will try the config parameters you suggest.
Thanks
Christophe
Beniamin Janicki wrote:
:so you can send your updates anytime you want, and as long as you
erver running two cores ? Any such config already tested ?
I guess that the standard replication based on rsync can be simplified a
lot in this case as the two indexes are on the same server.
Thanks
Christophe
Beniamin Janicki wrote:
:so you can send your updates anytime you want, and as long a
Hi,
Is the new replication feature based on HTTP requests between sites ?
If yes, then I guess it might be possible to configure an HTTP server
with mod_deflate so the data is compressed on the fly.
C.
Simon Collins wrote:
I have now optimized the index - down to 325mb, it compresses down to
Hi,
I'm doing the following query:
q=text:abc AND type:typeA
And I ask to return highlighting (query.setHighlight(true);). The search
term for field "type" (typeA) is also highlighted in the "text" field.
Anyway to avoid this ?
Thanks
Christophe
Hi Lars,
Thanks for it: it works great.
BR
Christophe
Lars Kotthoff wrote:
I'm doing the following query:
q=text:abc AND type:typeA
And I ask to return highlighting (query.setHighlight(true);). The search
term for field "type" (typeA) is also highlighted in the "text"
Gziping on disk requires quite some I/O. I guess that on the fly zipping
should be faster.
C.
Walter Underwood wrote:
About a factor of 2 on a small, optimized index. Gzipping took 20 seconds,
so it isn't free.
$ cd index-copy
$ du -sk
134336 .
$ gzip *
$ du -sk
62084 .
wunder
On 10/30/0
Does the number of searcher affect CPU usage ?
Not totally sure about it but I think some versions of Tomcat were not
totally scalable over 4 CPUs (or 4 cores).
C.
wojtekpia wrote:
Yes, I am seeing evictions. I've tried setting my filterCache higher, but
then I start getting Out Of Memory exc
I haven't been able to find what makes a function query count as a match
when used a part of a boolean query with Occur.MUST.
A Term query is simple, if the term is not found, it doesn't count as a
match. What's the equivalent for a function query? A score of zero (or less
than zero, as implied by
The class SortableFloatFieldSource cannot be accessed from outside its
package. So it can't be used as part of a FunctionQuery.
Is there a workaround to this, or should I roll my own? Will it be fixed in
1.4?
magination.com
>
>
> On Wed, Aug 26, 2009 at 6:23 PM, Christophe
> Biocca wrote:
> > The class SortableFloatFieldSource cannot be accessed from outside its
> > package. So it can't be used as part of a FunctionQuery.
> > Is there a workaround to this, or should I roll my own? Will it be fixed
> in
> > 1.4?
> >
>
uggestions would be highly appreciated.
Thank you.
Christophe
--
View this message in context:
http://www.nabble.com/Solr---Tomcat-bottleneck-while-parsing-http-headers-tp18214387p18214387.html
Sent from the Solr - User mailing list archive at Nabble.com.
19 matches
Mail list logo