I swithced my code over to the Jetty client and did the same graphing. Like the Apache client I see up to 3 seconds at the start and the shoots down to ~20ms after. So I am inclinded to agree; I think it is DNS or some other network related issue.
I will try and track down exactly what. Whatever it is, maybe it could be "precomputed" to save time. Bill- On Jul 15, 2011 4:07 PM, "Oleg Kalnichevski" <[email protected]> wrote: > On Fri, 2011-07-15 at 15:40 -0400, Bill Speirs wrote: >> On Fri, Jul 15, 2011 at 2:56 PM, Oleg Kalnichevski <[email protected]> wrote: >> > What makes you think the time was wasted inside HttpClient code? >> >> I've re-run the test quite a few times (both with ab and the benchmark >> code) and EVERY time it's the first 100 requests. I'm only tracking >> the time around the execute() function, so it's coming from something >> the client is doing. >> > > Still, it may be a problem with your DNS or some other networking issue > completely outside of HttpClient's control. > >> >> I don't think it's that easy to say the first ones are simply >> irrelevant. In my benchmark they're all irrelevant; however, in >> production there will possibly be a human sitting behind that request >> (or a 100 in this case) and they will have to wait for 6 seconds >> whereas everyone else will only have to wait a ~20ms. > > I have a hard time believing that a bug causing performance degradation > from 20 milliseconds to 6 second could have gone undetected for so long, > but I have mistaken before. By all of means please do continue digging. > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
