Not snobbish at all, I greatly appreciate any & all time you can throw at my problem :)
Thanks! Dominic On Thu, 21 Oct 2021 at 17:39, Deepak Goel <[email protected]> wrote: > That's a good one. I will have to check the post-replication code of Solr > to answer your question (I can give it a shot on the weekend if I get the > time, sorry for sounding snobbish) > > Deepak > "The greatness of a nation can be judged by the way its animals are treated > - Mahatma Gandhi" > > +91 73500 12833 > [email protected] > > Facebook: https://www.facebook.com/deicool > LinkedIn: www.linkedin.com/in/deicool > > "Plant a Tree, Go Green" > > Make In India : http://www.makeinindia.com/home > > > On Thu, Oct 21, 2021 at 9:57 PM Dominic Humphries > <[email protected]> wrote: > > > One more tidbit: I just tried leaving replication off for a few hours and > > then triggering a "big" replication run so I could see the distinct > stages. > > > > > > - Beginning replication didn't cause any performance degradation. > > - Several minutes of downloading the replication files saw no > > degradation > > - Only after downloading had completed did we start to see performance > > issues in our tests > > - But we saw the "number of docs/timestamp of latest file" both jump > > almost immediately after downloading completed and never move again > > - But the performance degradation continued for about seven more > minutes > > even though replication was clearly finished at this point > > > > > > Is there some kind of re-indexing optimization thing that solr can run > > post-replication? At this point it's about my only remaining suspect.. > > >
