Requests take >2x time inside JUCE on Mac

Hey! I’ve spent the entire night combing through the Mac networking code and it appears that there is a significant performance difference between URLConnectionState & URLConnectionStatePreYosemite

I have a set of post requests I’m trying to perform with JUCE. I’ve checked all the requests in both CURL & Postman, the difference being that Postman can support HTTP Keep Alive while CURL cannot.

I observed the request speeds were >2x slower while running inside of JUCE for a fairly large payload response.

I looked through how the NSURL stuff is working, it’s not my specialty but after reading how others were using these features, JUCE does seem to deviate from the recommendations by creating NSURLSessions for every request. I believe this may defeat the purpose of NSURLSession. In fact – persisting one across all requests may solve these issues and bring significant request speed improvements to JUCE.

In a final Hail Mary at the end of the night here, I saw this code:

if (@available (macOS 10.10, *))
    connection = std::make_unique<URLConnectionState> (req, numRedirectsToFollow);
    connection = std::make_unique<URLConnectionStatePreYosemite> (req, numRedirectsToFollow);

I decided to try URLConnectionStatePreYosemite, and my request speeds went back to normal! – for the large request it was a 2x faster, and for smaller requests is was 4x faster.

Is it possible to review this, and perhaps ditch the NSURLSession if it’s slowing things down? On the flip, these requests run 5x faster under a keep alive, so (although I’m not sure) it might bring serious benefits to make this somehow persist over the life cycle of the JUCE app.

1 Like

Unfortunately I’ve had to fork JUCE for now until this is resolved, I’ve managed to make it so many years without having to do so, but it appears there’s no simplistic way to create a modified version of the Mac network layer without forking and editing it directly.

1 Like