Thanks for the replies. I made the changes so that the external file field
is loaded per:
On 10/8/2016 1:18 PM, Mike Lissner wrote:
> I want to make sure I understand this properly and document this for
> futurepeople that may find this thread. Here's what I interpret your
> advice to be:
> 0. Slacken my auto soft commit interval to something more like a minute.
Yes, I would do this.
I chose 16 as a place to start. You usually reach diminishing returns
pretty quickly, i feel it's a mistake to set your autowarm counts to, say
256 (and I've seen this in the thousands) unless you have some proof
that it's useful to bump higher.
But certainly if you set them to 16 and see spikes j
With time-oriented data, you can use an old trick (goes back to Infoseek in
1995).
Make a “today” collection that is very fresh. Nightly, migrate new documents to
the “not today” collection. The today collection will be small and can be
updated
quickly. The archive collection will be large and
On Fri, Oct 7, 2016 at 8:18 PM Erick Erickson
wrote:
> What you haven't mentioned is how often you add new docs. Is it once a
> day? Steadily
> from 8:00 to 17:00?
>
Alas, it's a steady trickle during business hours. We're ingesting court
documents as they're posted on court websites, then sendi
On Sat, Oct 8, 2016 at 8:46 AM Shawn Heisey wrote:
> Most soft commit
> > documentation talks about setting up soft commits with of
> about a
> > second.
>
> IMHO any documentation that recommends autoSoftCommit with a maxTime of
> one second is bad documentation, and needs to be fixed. Where h
On 10/7/2016 6:19 PM, Mike Lissner wrote:
> Soft commits seem to be exactly the thing for this, but whenever I open a
> new searcher (which soft commits seem to do), the external file is
> reloaded, and all queries are halted until it finishes loading. When I just
> measured, this took about 30 sec
bq: Most soft commit
documentation talks about setting up soft commits with of about a
second.
I think this is really a consequence of this being included in the
example configs
for illustrative purposes, personally I never liked this.
There is no one right answer. I've seen soft commit interval
we had been doing some work with this, and had gotten to the
architecture stage on this at $WORK, but the guy who was leading the
charge got put onto other tasks, and left before having a chance to
implement it, and our priorities shifted to other things ;(
From what I remember, there are seve
if new data come in and drive index it, load new search it.
if more docs, optimize time will cost much, so can't do search like real
time.
so i think new solr instance only for newest information. the docs will
be ~10K.
if it arrive 10k, it should be closed and rebuild new instance.
(if we have m
it seems use somthing like ajax...
if so, it not what i wanna
2007/9/25, Matthew Runo <[EMAIL PROTECTED]>:
>
> I assume you mean something like this:
>
> http://addictedtonew.com/archives/145/wordpress-live-search-plugin/
>
> Take a look at how the search box works - is that what you mean?
>
>
>
I assume you mean something like this:
http://addictedtonew.com/archives/145/wordpress-live-search-plugin/
Take a look at how the search box works - is that what you mean?
++
| Matthew Runo
| Zappos Development
| [EMAIL PROTECTED]
| 7
Hi James,
Can you provide more information about what you are trying to do? By
real time search, do you mean you want indexed documents to be
available immediately? Or is a minute or two acceptable? Do all
users need to see them immediately, or just the current user?
We can better help
13 matches
Mail list logo
