RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-18 Thread Bryan Loofbourrow
Bryan Loofbourrow [mailto:bloofbour...@knowledgemosaic.com] > Sent: Tuesday, June 18, 2013 5:16 PM > To: 'solr-user@lucene.apache.org' > Subject: RE: Slow Highlighter Performance Even Using FastVectorHighlighter > > Andy, > > OK, I get what you're doing. As far as a

RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-18 Thread Bryan Loofbourrow
ur query (or, at least, terms > matching exact words or the beginning of phrases in your query) is > extremely high . Perhaps that's coming from this "partial word match" > you > mention -- how does that work? > > -- Bryan > > > My guess is that this has som

Re: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-17 Thread Floyd Wu
. > >> Again, I'm using the FastVectorHighlighting. The hl.fl is set to "name > >> name_par description description_par content content_par" so that it > >> returns highlights for full and partial word matches. All of those > >> fields have indexed,

Re: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-15 Thread Michael McCandless
hraseList.addIfNoOverlap( >>> >>> ) >> >> That is a strange and interesting set of things to be spending most of >> your CPU time on. The implication, I think, is that the number of term >> matches in the document for terms in your query

Re: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-15 Thread Michael Sokolov
set to "true". It all seems redundant just to allow for partial word matching/highlighting but I didn't know of a better way. Does anything stand out to you that could be the culprit? Let me know if you need any more clarification. Thanks! - Andy -Original Message--

RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-06-14 Thread Andy Brown
set to "true". It all seems redundant just to allow for partial word matching/highlighting but I didn't know of a better way. Does anything stand out to you that could be the culprit? Let me know if you need any more clarification. Thanks! - Andy -Original Message

RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-05-29 Thread Bryan Loofbourrow
not, buy more memory (I don't > know > why that wa number makes sense, I just know that it has been a good rule > of thumb for us). > > -- Bryan > > > -Original Message- > > From: Andy Brown [mailto:andy_br...@rhoworld.com] > > Sent: Monday, May 20, 2013

RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-05-22 Thread Andy Brown
che.org Subject: RE: Slow Highlighter Performance Even Using FastVectorHighlighter My guess is that the problem is those 200M documents. FastVectorHighlighter is fast at deciding whether a match, especially a phrase, appears in a document, but it still starts out by walking the entire list of term vect

RE: Slow Highlighter Performance Even Using FastVectorHighlighter

2013-05-20 Thread Bryan Loofbourrow
w why that wa number makes sense, I just know that it has been a good rule of thumb for us). -- Bryan > -Original Message- > From: Andy Brown [mailto:andy_br...@rhoworld.com] > Sent: Monday, May 20, 2013 9:53 AM > To: solr-user@lucene.apache.org > Subject: Slow Highlighter

Slow Highlighter Performance Even Using FastVectorHighlighter

2013-05-20 Thread Andy Brown
I'm providing a search feature in a web app that searches for documents that range in size from 1KB to 200MB of varying MIME types (PDF, DOC, etc). Currently there are about 3000 documents and this will continue to grow. I'm providing full word search and partial word search. For each document, the