Our document contains a total of 23 fields in one document and we STORE all
of them in lucene index.
We have recently had some performance issues and our analysis has shown the
bottleneck to be lucene search and retrieval.
We have been thinking about reducing the number of fields per document b
server based cookie.
>
> Ie. Instead of setting the cookie access for a server (eg.
> server1.mydomain.com), set it for the domain (eg. .mydomain.com, don't
> forget the "dot" before the domain name).
>
> Regards,
> kapilChhabra
>
> -Original Message
Hi Everyone,
We are planning on scaling our current web server by adding a machine with
similar specification. Both machine will be running lucene searches. What we
plan to do is add a load balancer in front of these servers. Our requirement
is to be able to share user info (user search history,
evel of complexity. Can you provide info about number of
>> > documents,
>> > > # of updates, # of queries etc. ? What kind of analysis, etc. are
>> > > you doing? That being said, putting the web app on one
>> > machine and
>> > > the search application on the ot
plication
> capabilities for load balancing search servers. I think it answers
> the question in favor of the POST/GET approach. In fact, you may be
> able to drop in Solr to your situation w/o too much work.
>
> Cheers,
> Grant
>
>
> On Jul 15, 2007, at 10:10 PM, kum
Hi Everyone,
We are using lucene,nutch and spring framework to create a specialized
search engine. Due to growing traffic we are trying to scale. By doing some
tests we found out that the bottle neck was lucene search. We used some
heavy traffic simulation and logged the time taken by each portio
