[ 
https://issues.apache.org/jira/browse/MRESOLVER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651222#comment-17651222
 ] 

Tamas Cservenak edited comment on MRESOLVER-308 at 12/22/22 11:03 AM:
----------------------------------------------------------------------

Third round, the transports can be considered feature complete (while the 
project has now quite a lot of redundancy, like the test HTTP server, this 
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT

Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central

        A      B
wagon   00:49  01:18
native  00:45  00:50
jetty   00:45  00:51
okhttp  00:53  00:51
java11  00:41  00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is 
slowest, while native is rock solid and performant, but both are (and can be 
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP 
socket used, which may be interesting on CI server for example).

OkHttp is faster then wagon, but by a margin, plus it pulls in kotlin, that is 
I think undesired, so I'd eliminate it.

The two remaining contenders, Jetty and Java11 HttpClient are both interesting. 
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient 
is requirement of Java11 (but it is currently circumvented cleanly, so this 
transport can exist even in Maven 3.9.0 but remains dormant if Java8 used, 
while activates when Java11+ used).


was (Author: cstamas):
Third round, the transports can be considered feature complete (while the 
project has now quite a lot of redundancy, like the test HTTP server, this 
would yield a cleanup):
{noformat}
Java: 17.0.5 Temurin
Maven 3.9.0-SNAPSHOT

Cases:
A) building maven-resolver against Google Central Mirror (EU)
B) building maven-resolver against Maven Central

        A      B
wagon   00:49  01:18
native  00:45  00:50
jetty   00:45  00:51
okhttp  00:53  00:51
java11  00:41  00:50{noformat}
Conclusion: Regarding existing transports, wagon is "battle tested", but is 
slowest, while native is rock solid and performant, but both are (and can be 
only) HTTP/1.1. The HTTP/2 is definitely better at least in C10k area (one TCP 
socket used, which may be interesting on CI server for example).

OkHttp is faster then wagon, but by a margin, plus it pulls in kotlin, that is 
I think undesired, so I'd eliminate it.

The two remaining contenders, Jetty and Java11 HttpClient are both interesting. 
Con for Jetty is relatively big dependency trail, while for Java11 HttpCiient 
is need of Java11.

> HTTP transport showdown
> -----------------------
>
>                 Key: MRESOLVER-308
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-308
>             Project: Maven Resolver
>          Issue Type: Task
>          Components: Resolver
>            Reporter: Tamas Cservenak
>            Priority: Major
>
> For HTTP protocol resolver currently provides following transports:
>  * transport-wagon that uses Maven 2.x Wagon, that among other protocols 
> supports HTTP/1.1 as well
>  * transport-http that uses directly Apache HttpClient 4.x supporting 
> HTTP/1.1 but provides enhancements in form of "checksum strategy" (almost all 
> of remote repositories emit those in headers, sparing one HTTP round-trip)
> As we saw, is very easy to outperform these as:
>  * Maven Central supports HTTP/1.1 but also HTTP/2
>  * HTTP/3 is on the way as well
> An experiment involving Jetty Client far outperformed both of existing 
> transports, most probably due HTTP/2 support.
> So, clients we should consider:
>  * Jetty Client
>  * OkHTTP
>  * Java 11 HttpClient
> Point is, to invest into something that (ideally) transparently supports 
> HTTP/1.1 and HTTP/2, and more ideal would be if even HTTP/3 would be 
> transparently supported (Jetty 12 works on that). We could then simply 
> compare these implementations, count in pros and cons, and decide where we 
> want to go,



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to