I am pleased to report that we are in Production on Solr 5.5.3 with
comparable performance to Solr 4.8.1 through leveraging facet.method=uif as
well as https://issues.apache.org/jira/browse/SOLR-9176. Thanks to
everyone who worked on these!
On Mon, Oct 3, 2016 at 3:55 PM, Solr User wrote:
> Bel
Below is some further testing. This was done in an environment that had no
other queries or updates during testing. We ran through several scenarios
so I pasted this with HTML formatting below so you may view this as a
table. Sorry if you have to pull this out into a different file for
viewing,
I plan to re-test this in a separate environment that I have more control
over and will share the results when I can.
On Wed, Sep 28, 2016 at 3:37 PM, Solr User wrote:
> Certainly. And I would of course welcome anyone else to test this for
> themselves especially with facet.method=uif to see if
Certainly. And I would of course welcome anyone else to test this for
themselves especially with facet.method=uif to see if that has indeed
bridged the gap between Solr 4 and Solr 5. I would be very happy if my
testing is invalid due to variance, problem in process, etc. One thing I
was ponderin
On Tue, 2016-09-27 at 15:08 -0500, Solr User wrote:
> Further testing indicates that any performance difference is not due
> to deletes. Both Solr 4.8.1 and Solr 5.5.2 benefited from removing
> deletes.
Sanity check: Could you describe how you test?
* How many queries do you issue for each test?
Further testing indicates that any performance difference is not due to
deletes. Both Solr 4.8.1 and Solr 5.5.2 benefited from removing deletes.
The times appear to converge on an optimized index. Below are the
details. Not sure what else to make of this at this point other than
moving forward w
Hi !
At the time we didn't investigate the deletion implication at all.
This can be interesting.
if you proceed with your investigations and discover what changed in the
deletion approach, I would be more than happy to help!
Cheers
On Mon, Sep 26, 2016 at 10:59 PM, Solr User wrote:
> Thanks aga
Thanks again for your work on honoring the facet.method. I have an
observation that I would like to share and get your feedback on if possible.
I performance tested Solr 5.5.2 with various facet queries and the only way
I get comparable results to Solr 4.8.1 is when I expungeDeletes. Is it
possi
Interesting developments :
https://issues.apache.org/jira/browse/SOLR-9176
I think we found why term Enum seems slower in recent Solr !
In our case it is likely to be related to the commit I mention in the Jira.
Have a check Joel !
On Wed, May 25, 2016 at 12:30 PM, Alessandro Benedetti <
abenede
I am investigating this scenario right now.
I can confirm that the enum slowness is in Solr 6.0 as well.
And I agree with Joel, it seems to be un-related with the famous faceting
regression :(
Furthermore with the legacy facet approach, if you set docValues for the
field you are not going to be ab
The enum slowness is interesting. It would appear on the surface to not be
related to the FieldCache issue. I don't think the main emphasis of the
JSON facet API has been the enum approach. You may find using the JSON
facet API and eliminating the use of enum meets your performance needs.
With the
Joel,
Thank you for taking the time to respond to my question. I tried the JSON
Facet API for one query that uses facet.method=enum (since this one has a
ton of unique values and performed better with enum) but this was way
slower than even the slower Solr 5 times. I did not try the new API with
Yes, SOLR-8096 is the issue here.
I don't believe indexing with docValues is going to help too much with
this. The enum slowness may not be related, but I'm not positive about
that.
The major slowdowns are likely due to the removal of the top level
FieldCache from general use and the removal of t
Does anyone know the answer to this?
On Wed, May 4, 2016 at 2:19 PM, Solr User wrote:
> I recently was attempting to upgrade from Solr 4.8.1 to Solr 5.4.1 but had
> to abort due to average response times degraded from a baseline volume
> performance test. The affected queries involved faceting
I recently was attempting to upgrade from Solr 4.8.1 to Solr 5.4.1 but had
to abort due to average response times degraded from a baseline volume
performance test. The affected queries involved faceting (both enum method
and default) and grouping. There is a critical bug
https://issues.apache.org
15 matches
Mail list logo