Yeah, for network latency I would recommend a tool like charlesproxy. Edward
Em qui, 11 de jul de 2019 20:59, Erick Erickson <erickerick...@gmail.com> escreveu: > true, although there’s still network that can’t be included. > > > On Jul 11, 2019, at 5:55 PM, Edward Ribeiro <edward.ribe...@gmail.com> > wrote: > > > > Wouldn't be the case of using &rows=0 parameter on those requests? Wdyt? > > > > Edward > > > > Em qui, 11 de jul de 2019 14:24, Erick Erickson <erickerick...@gmail.com > > > > escreveu: > > > >> Not only does Qtime not include network latency, it also doesn't include > >> the time it takes to assemble the docs for return, which can be lengthy > >> when rows is large.. > >> > >> On Wed, Jul 10, 2019, 14:39 Shawn Heisey <apa...@elyograg.org> wrote: > >> > >>> On 7/10/2019 3:17 PM, Lucky Sharma wrote: > >>>> I am seeing one very weird behaviour of QTime of SOLR. > >>>> > >>>> Scenario is : > >>>> When I am hitting the Solr Cloud Instance, situated at a DC with my > >> local > >>>> machine while load test I was seeing 400ms Qtime response and 1sec > Http > >>>> Response time. > >>> > >>> How much data was in the response? If it's large, I can see it taking > >>> that long to transfer. This is even more likely if there is a lot of > >>> network latency in the network between the client and the server. > >>> > >>>> While I am trying to do the same process within the same DC location, > I > >>> am > >>>> getting 100 ms Solr QTime and 130ms Response Time. > >>>> > >>>> Does QTime counts network latency too?? > >>> > >>> There's no way Solr can include the time to send the response over the > >>> network in QTime. The value is calculated and put into the response > >>> before Solr starts sending. > >>> > >>> Thanks, > >>> Shawn > >>> > >> > >
