The remote web app will be accessing the Solr server via internet. Its not a intranet setup.
On Fri, Aug 7, 2009 at 10:19 AM, Walter Underwood <wun...@wunderwood.org>wrote: > About the first option, caches are more effective with more traffic, so ten > front end servers using three Solr servers will have better caching and > probably better overall performance than having separate search on all ten > servers. You can even put an HTTP cache in there and get better caching. > > Cached HTTP responses are usually faster than accessing disc locally. > > You say you have a "remote web application". How remote? If the indexes are > big, then copying them to a remote location is a lot of traffic. > > wunder > > On Aug 6, 2009, at 8:49 PM, Ninad Raut wrote: > > Hi Noble, >> Can you explain a bit more on how to use Solr "out of the box". I am >> looking at ways to design the UI for remote application quickly and with >> less problems. >> Also could you elaborate more on what can go wrong with the first option? >> Thanks. >> >> 2009/8/6 Noble Paul നോബിള് नोब्ळ् <noble.p...@corp.aol.com> >> >> On Thu, Aug 6, 2009 at 12:24 PM, Ninad Raut<hbase.user.ni...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> I have a search engine on Solr. Also I have a remote web application >>>> >>> which >>> >>>> will be using the Solr Indexes for search. >>>> I have three scenarios: >>>> 1) Transfer the Indexes to the Remote Application. >>>> >>>> - This will reduce load on the actual solr server and make seraches >>>> faster. >>>> - Need to write some code to transfer the index >>>> - Need to double my effort to update,merge,optimize index >>>> >>>> 2)Use HTTP GET >>>> >>>> - Will increase load on the Solr server >>>> - No extra code needed for transfer >>>> >>> This by far is the best solution. ecause you do not have to do any >>> work at all. It all works out of the box and that is what everyone >>> uses >>> >>>> >>>> 3) Embedded Serach >>>> >>>> - Use SolrJ for querying >>>> >>>> I want to know which is the best approach. >>>> Regards, >>>> Ninad Raut. >>>> >>>> >>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul | Principal Engineer| AOL | http://aol.com >>> >>> >
