Hi Ilan, yes, the system property remains the same (`node_type`).
I've uploaded a small proof of concept here
https://gist.github.com/ixai/39c450ce81ffeeb5776b5c6e93522fd8.
It contains one docker-compose file with 3 nodes, and a script to configure
and generate the collections.
Best,
Ixai
On Thu,
I think there are or were technical reasons behind it and thats something
to figure out. Its also more complicated than that, I just simplified it.
E.g. uniqueKey is actually a composition of two ids and relationship
between them is important for grouping purposes.
I agree with you on switching to
On 6/16/22 09:16, Christopher Schultz wrote:
We have our server set to soft-commit every 30 seconds.
30 seconds is very aggressive. It's far better than 1 second, but still
quite frequent.
If we know we are going to be sending a lot of documents at once, if
we set "commitWithin" to someth
May I ask why you haven't used the sku as (primary key)? Do you need to
have more versions of the same sku?
For my understanding, if you can have the sku as primary key, almost all
deleteByQuery are useless.
On Thu, Jun 16, 2022 at 4:38 PM Shawn Heisey wrote:
> On 6/16/22 02:59, Marius Grigaitis
All,
We have our server set to soft-commit every 30 seconds.
If we know we are going to be sending a lot of documents at once, if we
set "commitWithin" to something longer -- for those document-add/replace
requests, will that override the soft-commit setting, or will the
soft-commit setting j
On 6/16/22 02:59, Marius Grigaitis wrote:
In the end what caught our eye is a few deleteByQuery lines in stacks of
running threads while Solr is overloaded. We temporarily removed
deleteByQuery and it had around 10x performance improvement on indexing
speed.
I do not understand all the low-leve
Hi Vincenzo,
Yes.
On Thu, Jun 16, 2022 at 12:39 PM Vincenzo D'Amore
wrote:
> Hi Marius, if I have understood correctly you have a deleteByQuery for each
> document, am I right?
>
> On Thu, 16 Jun 2022 at 11:04, Marius Grigaitis
> wrote:
>
> > Just a followup on the topic.
> >
> > * We checked
Interesting find. I have seen other reports on very slow deleteByQuery earlier.
So it should be used sparingly, and under no circumstance bombard Solr with
multiple deleteByQuery requests on each update.
Sounds like a better plan to switch to a truly unique ID like SKU. Or if you
know the previ
Thanks a lot Ixai for the debugging work and PR (that looks good to me -
I'll merge it shortly).
As I understand you managed to make this work end to end, can you please
confirm that the per node system property to use (to match the "
collectionNodeType" config) is indeed node_type?
Thanks,
Ilan
Hi Marius, if I have understood correctly you have a deleteByQuery for each
document, am I right?
On Thu, 16 Jun 2022 at 11:04, Marius Grigaitis
wrote:
> Just a followup on the topic.
>
> * We checked settings on solr, seem quite default (especially on merge,
> commit strategies, etc)
> * We com
Just a followup on the topic.
* We checked settings on solr, seem quite default (especially on merge,
commit strategies, etc)
* We commit every 10 minutes
* Added NewRelic to the Solr instance to gather more data and graphs
In the end what caught our eye is a few deleteByQuery lines in stacks of
11 matches
Mail list logo
