Look at speed of reading the data - likely, it takes long time to assemble a big response, especially if there are many long fields - you may want to try SSD disks, if you have that option.
Also, to gain better understanding: Start your solr, start jvisualvm and attach to your running solr. Start sending queries and observe where the most time is spent - it is very easy, you don't have to be a programmer to do it. The crucial parts are (but they will show up under different names) are: 1. query parsing 2. search execution 3. response assembly quite likely, your query is a huge boolean OR clause, that may not be as efficient as some filter query. Your use case is actually not at all exotic. There will soon be a JIRA ticket that makes the scenario of sending/querying with large number of IDs less painful. http://lucene.472066.n3.nabble.com/Solr-large-boolean-filter-td4070747.html#a4070964 http://lucene.472066.n3.nabble.com/ACL-implementation-Pseudo-join-performance-amp-Atomic-Updates-td4077894.html But I would really recommend you to do the jvisualvm measurement - that's like bringing the light into darkness. roman On Thu, Jul 18, 2013 at 10:46 AM, Brian Hurt <bhur...@gmail.com> wrote: > I have a situation which is common in our current use case, where I need to > get a large number (many hundreds) of documents by id. What I'm doing > currently is creating a large query of the form "id:12345 OR id:23456 OR > ..." and sending it off. Unfortunately, this query is taking a long time, > especially the first time it's executed. I'm seeing times of like 4+ > seconds for this query to return, to get 847 documents. > > So, my question is: what should I be looking at to improve the performance > here? > > Brian >
