: Our runtime/search use-case is very simple: run filters to select all docs : that match some conditions specified in a filter query (we do not use : Lucene scoring) and return the first 100 docs that match (this is an : over-simplification)
"first" as defined how? in order collected by a custom collector, or via some sort? : On a machine with nothing else running, we are unable to move the needle on : CPU utilization to serve higher QPS. We see that most of the time is spent : in BlockTreeTermsReader.FieldReader.iterator() when we run profiling tools : to see where time is being spent. The CPU usage doesn't cross 30% (we have : multiple threads one per each client connected over a Jetty connection all : taken from a bounded thread-pool). We tried the usual suspects like : tweaking size of the threadpool, changing some jvm parameters like newsize, : heapsize, using cms for old gen, parnew for newgen, etc. You said you have one thread per client, but you didn't mention anything about varying the number of clients -- did you try increasing the number of clients hitting your application concurrently? It's possible that your box is "beefy" enough that 30% of the available CPU is all that's needed for the number of active concurrnt threads you are using (increasing hte size of the threadpool isn't going to affect anything if there aren't more clients utilizing those threads) -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
