-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
17
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
MacOS 11.6, JDK 17 build 35.
A DESCRIPTION OF THE PROBLEM :
I've written a very simple test using the HttpClient in a tight loop (100,000 iterations) and calling a simple web server. This test runs in about 36.7s. I then remove HttpClient and replace it with a HttpURLConnection implementation. The URLConnection implementation runs in about 27.6s.
I haven't done a lot of analysis or looked at the difference in these two implementations for HTTP, but it was very surprising that the HttpClient, which seems to be the new recommended way to make HTTP requests, is that might slower than good old HttpURLConnection. I was expecting it to make heavy use of Selectors and Channels and ideally be even faster than HttpURLConnection. It could even use shared memory buffers to reduce GC, but it doesn't appear to do any of that.
Just thought I would make a suggestion to try and improve on the HttpClient since it would be great to have a good way to call APIs in the JDK.
MacOS 11.6, JDK 17 build 35.
A DESCRIPTION OF THE PROBLEM :
I've written a very simple test using the HttpClient in a tight loop (100,000 iterations) and calling a simple web server. This test runs in about 36.7s. I then remove HttpClient and replace it with a HttpURLConnection implementation. The URLConnection implementation runs in about 27.6s.
I haven't done a lot of analysis or looked at the difference in these two implementations for HTTP, but it was very surprising that the HttpClient, which seems to be the new recommended way to make HTTP requests, is that might slower than good old HttpURLConnection. I was expecting it to make heavy use of Selectors and Channels and ideally be even faster than HttpURLConnection. It could even use shared memory buffers to reduce GC, but it doesn't appear to do any of that.
Just thought I would make a suggestion to try and improve on the HttpClient since it would be great to have a good way to call APIs in the JDK.