On Mar 29, 2012, at 14:49 , fbrisbart wrote: > Arf, I didn't see your attached tgz. > > In your slave solrconfig.xml, only the 'firstSearcher' contains the > query. Add it also in the 'newSearcher', so that the new search > instances will wait also after a new index is replicated.
Did that now, but I believe my case is mostly a first searcher issue. Anyway it didn't seem to change anything. > > The first request is long because the default faceting method uses the > FieldCache for your facet fields. Jup, i know. > You may also choose to use the facet.method=enum The performance is > globally worse You say. This means that every search with facets is now 20 seconds instead of 2. Then I prefer the field cache with one bad first search. > than the 'fc' method, but you will avoid the very slow > first request. Btw, it's far better to use the default 'enum' facet > method. Thanks for the input so far. > > Hope this helps, > Franck > > > > > > > Le jeudi 29 mars 2012 à 13:57 +0200, fbrisbart a écrit : >> If you add your query to the firstSearcher and/or newSearcher event >> listeners in the slave >> 'solrconfig.xml' ( >> http://wiki.apache.org/solr/SolrCaching#newSearcher_and_firstSearcher_Event_Listeners >> ), >> >> each new search instance will wait before accepting queries. >> >> Example to load the FieldCache for 'your_facet_field' field : >> ... >> <listener event="firstSearcher" class="solr.QuerySenderListener"> >> <arr name="queries"> >> <lst><str name="q">*:*</str><str name="facet">true</str><str >> name="facet.field">your_facet_field</str></lst> >> </arr> >> </listener> >> ... >> >> >> Franck >> >> Le jeudi 29 mars 2012 à 13:30 +0200, Dennis Schafroth a écrit : >>> Hi >>> >>> I am running indexing and facetted searching on bibliographic data, which >>> is known not to perform to well due to the high facet count. Actually it's >>> just the firstSearch that is horrible slow, 200+ seconds . After that, I >>> am getting okay times (1 second) (at least in a few users scenario we have >>> now). >>> >>> The current index is 54 millions record with approx. 10 millions unique >>> authors. The facets (… _exact) is using the string type. >>> >>> I had hoped that a master (indexing) and slave (searching) would have >>> solved the issue, but I am still seeing the issue on the slave, so I guess >>> I must have misunderstood (or perhaps misconfigured) something >>> >>> I had thought that the slave would not switch to the new index until the >>> auto warming was completed. Is such behavior possible? >>> >>> I guess a alternative solution could be to have multiple slaves and taking >>> a slave off-line when doing replication, but if it is possible to do >>> simpler (and using 1/3 less space) that would be great. Then again we might >>> need multiple slaves with more requests. >>> >>> Attached is the configuration files. >>> >>> Let me know if there is missing information. >>> >>> cheers, >>> :-Dennis Schafroth >>> >> >> > > >
