And I guess, if only a subset of fields is being requested but there are
other large fields present, there could be the cost of loading those extra
fields into memory before discarding them. In which case,
using enableLazyFieldLoading may help.

Regards,
   Alex.

Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)


On Thu, Jul 18, 2013 at 11:47 AM, Roman Chyla <roman.ch...@gmail.com> wrote:

> 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
> >
>

Reply via email to