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 CollapsingQParserPlugin top_fc is definitely faster during queries. The tradeoff is slower warming times and increased memory usage if the collapse fields are used in faceting, as faceting will load the field into a different cache. Joel Bernstein http://joelsolr.blogspot.com/ On Wed, May 18, 2016 at 5:28 PM, Solr User <solr...@gmail.com> wrote: > 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 > the non-enum queries though so I will give that a go. It looks like Solr > 5.5.1 also has a facet.method=uif which will be interesting to try. > > If these do not prove helpful, it looks like I will need to wait for > SOLR-8096 to be resolved before upgrading. > > Thanks also for your comment on top_fc for the CollapsingQParser. I use > collapse/expand for some queries but traditional grouping for others due to > performance. It will be interesting to see if those grouping queries > perform better now using CollapsingQParser with top_fc. > > On Wed, May 18, 2016 at 11:39 AM, Joel Bernstein <joels...@gmail.com> > wrote: > > > 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 the FieldValuesCache which > > was used for multi-value field faceting. > > > > The JSON facet API covers all the functionality in the traditional > > faceting, and it has been developed to be very performant. > > > > You may also want to see if Collapse/Expand can meet your applications > > needs rather Grouping. It allows you to specify using a top level > > FieldCache if performance is a blocker without it. > > > > > > > > > > Joel Bernstein > > http://joelsolr.blogspot.com/ > > > > On Wed, May 18, 2016 at 10:42 AM, Solr User <solr...@gmail.com> wrote: > > > > > Does anyone know the answer to this? > > > > > > On Wed, May 4, 2016 at 2:19 PM, Solr User <solr...@gmail.com> 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 (both enum > > > method > > > > and default) and grouping. There is a critical bug > > > > https://issues.apache.org/jira/browse/SOLR-8096 currently open > which I > > > > gather is the cause of the slower response times. One concern I have > > is > > > > that discussions around the issue offer the suggestion of indexing > with > > > > docValues which alleviated the problem in at least that one reported > > > case. > > > > However, indexing with docValues did not improve the performance in > my > > > case. > > > > > > > > Can someone please confirm or correct my understanding that this > issue > > > has > > > > no path forward at this time and specifically that it is already > known > > > that > > > > docValues does not necessarily solve this? > > > > > > > > Thanks in advance! > > > > > > > > > > > > > > > > > >
