http://en.wikipedia.org/wiki/Google_platform
Document server summarization
On Thu, Feb 5, 2009 at 12:57 PM, Michael Stoppelman wrote:
> On Thu, Feb 5, 2009 at 12:47 PM, Michael Stoppelman >wrote:
>
> >
> >
> > On Thu, Feb 5, 2009 at 9:05 AM, Jason Rutherglen <
> > jason.rutherg...@gmail.com> wr
On Thu, Feb 5, 2009 at 12:47 PM, Michael Stoppelman wrote:
>
>
> On Thu, Feb 5, 2009 at 9:05 AM, Jason Rutherglen <
> jason.rutherg...@gmail.com> wrote:
>
>> Google uses dedicated highlighting servers. Maybe this architecture would
>> work for you.
>>
>
> What's your reference? I used to work at
On Thu, Feb 5, 2009 at 9:05 AM, Jason Rutherglen wrote:
> Google uses dedicated highlighting servers. Maybe this architecture would
> work for you.
>
What's your reference? I used to work at Google.
>
> On Mon, Feb 2, 2009 at 11:24 PM, Michael Stoppelman >wrote:
>
> > Hi all,
> >
> > My sear
Google uses dedicated highlighting servers. Maybe this architecture would
work for you.
On Mon, Feb 2, 2009 at 11:24 PM, Michael Stoppelman wrote:
> Hi all,
>
> My search backends are only able to eek out 13-15 qps even with the entire
> index in memory (this makes it very expensive to scale). A
009 3:53 PM
To: java-user@lucene.apache.org
Subject: Re: Poor QPS with highlighting
> Can you describe this in a little more detail; I'm not exactly sure
what you
> mean.
>
Break your large text documents into multiple Lucene documents. Rather
than dividing them up into entirely di
Thanks Mark for the explanation. I think your solution would definitely
change the tf-idf scoring for documents since your field is now split up
over multiple docs. One option to get around the changing scoring would be
to to run a completely separate index for highlighting (with the overlapping
d
Can you describe this in a little more detail; I'm not exactly sure what you
mean.
Break your large text documents into multiple Lucene documents. Rather
than dividing them up into entirely discreet chunks of text consider
storing/indexing *overlapping* sections of text with an overlap as
a little more detail; I'm not exactly sure what you
mean.
> Cheers
> Mark
>
>
>
> - Original Message
> From: Michael Stoppelman
> To: java-user@lucene.apache.org
> Sent: Tuesday, 3 February, 2009 7:24:06
> Subject: Poor QPS with highlighting
>
>
g
Sent: Tuesday, 3 February, 2009 7:24:06
Subject: Poor QPS with highlighting
Hi all,
My search backends are only able to eek out 13-15 qps even with the entire
index in memory (this makes it very expensive to scale). According to my
YourKit profiler 80% of the program's time ends up in highlig
Hi all,
My search backends are only able to eek out 13-15 qps even with the entire
index in memory (this makes it very expensive to scale). According to my
YourKit profiler 80% of the program's time ends up in highlighting. With
highlighting disabled my backend gets about 45-50 qps (cheaper scalin
10 matches
Mail list logo
