Solr really isn't designed for that kind of use case. If it happens to work
well for your particular situation, great, but don't complain when you are
well outside the normal usage for a "search engine" (10, 20, 50, 100 results
paged at a time, with modest sized query strings.)
If you must get these 837 documents, do them in reasonable size batches,
like 20, 50, or 100 at a time.
That said, there may be something else going on here, since a query for 837
results should not take 4 seconds anyway.
Check QTime - is it 4 seconds?
Add debugQuery=true to your query and check the individual module times -
which ones are the biggest hogs? Or, maybe it is none of them and the
problem is elsewhere, like formatting the response, network problems, etc.
Hmmm... I wonder if the new real-time "Get" API would be better for your
case. It takes a comma-separated list of document IDs (keys). Check it out:
http://wiki.apache.org/solr/RealTimeGet
-- Jack Krupansky
-----Original Message-----
From: Brian Hurt
Sent: Thursday, July 18, 2013 10:46 AM
To: solr-user@lucene.apache.org
Subject: Getting a large number of documents by id
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
