: Although I haven't tried yet, I can't imagine that this request returns in : sub-zero seconds, which is what I want (having a index of about 1M docs with : 6000 fields/ doc and about 10 complex facetqueries / request).
i wouldn't neccessarily assume that :) If you have a request handler which does a query with a facet.field, and then does a followup query for the top N constraings in that facet.field, the time needed to execute that handler on a cold index should primarily depend on the faceting aspect and how many unique terms there are in that field. try it and see. : The navigation-pages are pretty important for, eh well navigation ;-) and : although I can rely on frequent access of these pages most of the time, it : is not guarenteed (so neither is the caching) if i were in your shoes: i wouldn't worry about it. i would setup "cold cache warming" of the important queries using a firstSearcher event listener, i would setup autowarming on the caches, i would setup explicit warming of queries using sort fields i care about in a newSearcher event listener, andi would make sure to tune my caches so that they were big enough to contain a much larger number of entries then are used by my custom request handler for the queris i care about (especially if my index only changed a few times a day, the caches become a huge win in that case, so throw everything you've got at them) and for the record: i've been in your shoes. >From a purely theoretical standpoint: if enough other requests are coming in fast enough to expunge the objects used by your "important" navigation pages from the caches ... then those pages aren't that important (at least not to your end users as an aggregate) on the other hand: if you've got discreet pools of users (like say: customers who do searches, vs your boss who thiks navigation pages are really important) then another appraoch is to have to ports searching queries -- one that you send your navigation type queries to (with the caches tuned appropriately) and one that you send other traffic to (with caches tuned appropriately) ... i do that for one major index, it makes a lot of sense when you have very distinct usage profiles and you want to get the most bang for your buck cache wise. : > #1 wouldn't really accomplish what you want without #2 as well. : regarding #1. : Wouldn't making a user-cache for the sole-purpose of storing these queries : be enough? I could then reference this user-cache by name, and extract the only if you also write a custom request handler ... that was my point before it was clear that you were already doing that no matter what (you had custom request handler listed in #2) you could definitely make sure to explicitly put all of your DocLists in your own usercache, that will certainly work. but frankly, based on what you've described about your use case, and how often your data cahnges, it would probably be easier to set up a layer of caching in front of Solr (since you are concerned with ensuring *all* of the date for these important pages gets cached) ... something like an HTTP reverse proxy cache (aka: acelerator proxy) would help you ensure that thes whole pages were getting cached. i've never tried it, but in theory: you could even setup a newSearcher event listener to trigger a little script to ping your proxy with a request thatforced it to revalidate the query when your index changes. -Hoss
