Sticky sessions only help for later pages. They don’t direct new queries to servers that already have that query cached. That is a bigger win than second pages.
I’ve thought about making a hash of the query-meaningful params (q, bq, …) and routing based on that, but that has other problems. When one server goes down, you simultaneously blow out every cache, which can cause cascading server overload. This is an actual problem, that took down the Infoseek search engine years ago. All the servers went down like dominos. There are some hashing approaches to fix this, but testing gets difficult. If you want really effective caching, put an HTTP cache in front of the load balancer. That is way better than fussing with request routing and the testing is minimal, because cache servers are designed to do exactly that. I did some benchmarks, and Varnish caching was slightly faster than the caching in a single Solr server. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Dec 13, 2022, at 11:27 AM, David Hastings <hastings.recurs...@gmail.com> > wrote: > > Ah, that makes sense. If you can do sticky sessions and such with your > balancers, plus I never had to deal with the throughput of something like > Netflix, so for mine and most use cases, I still feel one very hot server > is better than N warm ones. > > "but AWS load balancers aren’t very smart." - agreed, but it looks like > they attempted something for it: > https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html > > but can you sticky session an app server to a solr server? > Like > user->loadbalancer->app server X->solr load blancer->solr server X > and make sure that app server X- and solr server X stay connected for the > user's session? would love to see how to configure this > > > On Tue, Dec 13, 2022 at 1:53 PM Walter Underwood <wun...@wunderwood.org> > wrote: > >> I’ve always run load balancers, starting with Solr 1.2 at Netflix. >> Failover (cold) spares have cold caches, so have slow performance until the >> cache fills. I configure N+1 capacity, where N servers can handle the >> expected load, then we add one for failure handling. All the spares are hot. >> >> I even run updates to Solr Cloud through a load balancer. It is easy to >> configure and Solr is very efficient at forwarding documents to shard >> leaders. It is nice to have a separate load balancer for updates to split >> out query and update load monitoring and alerting. >> >> With a smart load balancer, you could send the same query back to the same >> host, but AWS load balancers aren’t very smart. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >>> On Dec 13, 2022, at 3:50 AM, Dave <hastings.recurs...@gmail.com> wrote: >>> >>> Ha I meant qtimes not atone. Also in general you shouldn’t use a load >> balancer with solr, since you won’t be able to keep the index hot and n >> memory for each subsequent query if you are paging through results. The >> best way in my experience is to have failovers for your nodes, instead of >> load balancing. >>> >>>> On Dec 13, 2022, at 12:13 AM, Shawn Heisey <apa...@elyograg.org> wrote: >>>> >>>> On 12/12/22 13:14, Pradeep wrote: >>>>> How to check time taken by solr to execute api? Also can you share me >> solr >>>>> doc how we can query manually solr index for specific record or any >> api's >>>>> you can provide. >>>> >>>> Not entirely sure what you are asking here. I will try to answer what >> I can discern. >>>> >>>> In solr.log, each query is logged if you don't change the default >> logging levels. Each of those log lines will include a qtime parameter, >> counting the number of milliseconds it took to execute the query. The >> amount of time it takes to build the response and send it over the network >> is not included in the qtime. >>>> >>>> I don't know anything about your index, so I wouldn't be able to give >> you explicit instructions for querying for a specific document. But in >> most cases a query string like "id:value" will return a specific document, >> assuming that the "id" field is your uniqueKey. >>>> >>>> Thanks, >>>> Shawn >>>> >> >>
