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

Tamas Cservenak edited comment on MRESOLVER-308 at 12/20/22 3:50 PM:
---------------------------------------------------------------------

{noformat}
Test: building maven-resolver directly against central (supports h1 and h2) 
with empty local repo

Cmd: `mvn clean install -Dmaven.repo.local=local -Drat.skip -DskipTests` (plus 
transport swaps)

Java: 17.0.5 Temurin

Maven: 3.9.0-SNAPSHOT

wagon  h1      01:22  slowest
native h1+h+r  00:51  good but only H1
jetty  h2+h+r  00:52  good, but huge dep trail, Jetty 10.0.13
okhttp h2+h+r  00:55  slowest H2, brings in kotlin (relatively small dep trail: 
3 libs) OkHttp 4.10.0
java11 h2+h+r  00:49  clear winner (if we assume users run Maven on latest Java)

Legend:
h1 = HTTP/1.1
h2 = HTTP/2
h = extracts checksums from response headers
r = resumable download (can continue download if download was interrupted)

Note: okhttp and jetty client implementations are suboptimal, while java11 is 
not fully complete.
Planned to remove DAV support, today there is no need for it, but who uses DAV 
servers to deploy, should use "native". {noformat}
Tested sources [https://github.com/cstamas/maven-resolver/tree/http2-transports]

Note: Jetty surprised me as last time I measured something completely different 
(see here 
[https://github.com/eclipse/jetty.project/issues/8974#issuecomment-1333644782)] 
but back then it was Jetty 10.0.12 and today I use 10.0.13 and also this was 
against Central while that issues is about Google Central mirror, etc... but 
totally different numbers, And at the end, jetty transport code got changed 
quite a bit (and is sub-optimal).


was (Author: cstamas):
{noformat}
Test: building maven-resolver directly against central (supports h1 and h2) 
with empty local repo

Cmd: `mvn clean install -Dmaven.repo.local=local -Drat.skip -DskipTests` (plus 
transport swaps)

Java: 17.0.5 Temurin

Maven: 3.9.0-SNAPSHOT

wagon  h1      01:22  slowest
native h1+h+r  00:51  good but only H1
jetty  h2+h+r  00:52  good, but huge dep trail, Jetty 10.0.13
okhttp h2+h+r  00:55  slowest H2, brings in kotlin (but small dep trail: 3 
libs) OkHttp 4.10.0
java11 h2+h+r  00:49  clear winner (if we assume users run Maven on latest Java)

Legend:
h1 = HTTP/1.1
h2 = HTTP/2
h = extracts checksums from response headers
r = resumable download (can continue download if download was interrupted)

Note: okhttp and jetty client implementations are suboptimal, while java11 is 
not fully complete.
Planned to remove DAV support, today there is no need for it, but who uses DAV 
servers to deploy, should use "native". {noformat}
Tested sources [https://github.com/cstamas/maven-resolver/tree/http2-transports]

Note: Jetty surprised me as last time I measured something completely different 
(see here 
[https://github.com/eclipse/jetty.project/issues/8974#issuecomment-1333644782)] 
but back then it was Jetty 10.0.12 and today I use 10.0.13 and also this was 
against Central while that issues is about Google Central mirror, etc... but 
totally different numbers, And at the end, jetty transport code got changed 
quite a bit (and is sub-optimal).

> 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