You perfectly know that the comparison is not fair because checksum transport is handled differently. You have to create identical conditions.
On 2023/10/13 08:11:32 Tamás Cservenák wrote: > Howdy, > > Re perf (and this was already discussed about a year ago, please do not > derail discussion): look around > https://github.com/apache/maven-resolver/pull/231 and related JIRAs, there > are the numbers. TL;DR: jetty and jdk clients are consistently fastest and > are "side by side" (with the benefit of Jetty doing HTTP/3 as well, but > with the downside of huge dep trail), while Wagon is consistently the > slowest. Differences wildly differ but are very notable. > > Personally, I am not interested in doing a full rewrite of existing AHC > transport (as the expected amount of bugs doing this is pretty much on par > with doing fully new transport from scratch). I'd rather just choose a > library with a more stable API, like Jetty is. Moreover, forcing "async" > style in 2023 is something I'd avoid in today's written Java code (esp with > 21 virtual threads). But sure, if you want to do it, go for it (this work > would at least move Maven as a project forward, not backward). > > On Fri, Oct 13, 2023 at 9:52 AM Michael Osipov <micha...@apache.org> wrote: > > > Regardless of the names, the following questions code to my mind: > > > > * Does it make sense to put effort into too many clients? > > * How many users will actually switch the client? I bet < 10% > > > > olegk@ and me assessed many times on JIRA that HTTP/2 will have little > > performance benefit for our use case of transport. I'd like to see a move > > to Apache HttpClient 5 Async which does everything, but that is work. > > Having both AHC async and Jetty HTTP Client is a logical overlap and > > unnecessary maintenance burden. While I know nothing about the Jetty > > Client, the AHC (any version) has exceptional logging output down to bytes > > of streams which helps very often to analyze problem with users. > > > > I personally refuse and close out issue on JIRA where the user is not able > > to present that kind of debugging information. Poking in the dark. > > > > M > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
