Quantify slower, does it matter? At issue is that usually Solr spends far more time doing the search than transmitting the query and response over HTTP. Http is not really slow *as a protocol* in the first place.
The usual place people have problems here is when there are a bunch of requests made over a network, a "chatty" connection. Especially if the other end of the connection is far away. But in Solr's case, there's one request and one response per search, so there's not much chat to worry about. But regardless of all that, never, never, never make your environment more complex than it needs to be before you *demonstrate* that you need to. The efficiency savings are often negligible and the cost of maintaining the complexity are often far more than estimated. Premature optimization and all that. I will allow that on some rare occasions you *can* know that you have to get complex from the start, but I can't tell you how many times I've been *sure* I knew where the bottleneck would be....and been wrong. Measure first, fix second has become my mantra. Best Erick On Tue, Jan 17, 2012 at 3:49 AM, Maxim Veksler <ma...@vekslers.org> wrote: > On Tue, Jan 17, 2012 at 3:13 AM, Erick Erickson > <erickerick...@gmail.com>wrote: > >> I don't see why not. I'm assuming a *nix system here so when Solr >> updated an index, any deleted files would hang around. >> >> But I have to ask why bother with the Embedded server in the >> first place? You already have a Solr instance up and running, >> why not just query that instead, perhaps using SolrJ? >> >> > Wouldn't querying the Solr server using the HTTP interface be slower? > > >> Best >> Erick >> >> On Mon, Jan 16, 2012 at 3:00 PM, <spr...@gmx.eu> wrote: >> > Hi, >> > >> > is it possible to use the same index in a solr webapp and additionally >> in a >> > EmbeddedSolrServer? The embbedded one would be read only. >> > >> > Thank you. >> > >>