Performance issues when using the Network API used to create a web server

Here's a link to download a sample code that will run a server with the Network API and with the GCD API.

Instructions are included, in the "Instructions.txt" file, as you may have guessed. ;-) https://softron-downloads.s3.amazonaws.com/bvcwb546r7ret8hyj9tpm413a57zagf6qdf6h8/DualHTTPServer.zip

Thank you!

Pierre

Computer A (using macOS Tahoe or Sonoma)

You mean “macOS Tahoe or Sequoia”, right? That is, macOS 26 or macOS 15?

[My experience is that it’s better to stick with version numbers rather than names. In 5 years time, it’s gonna be really hard to remember whether macOS Sequoia came before or after macOS Sonoma.]

On computer B, make an HTTP request to download a 20MB file

Is this using your own HTTP client? Or URLSession? Or curl? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thank you for getting back to me.

Yes I do mean macOS 26 or macOS 15. Earlier macOS versions do not show the issue. Note that we only tested with macOS 15.6.1, macOS 26.0.1 and macOS 26.1 beta 3 and 4.

In the sample code and instructions that I provided, we can reproduce it with curl, but we have seen the issue first in our code where we use URLSession.

Let me know if you need additional information.

Pierre

Thanks for the extra.

Another question:

there is no issue when using WiFi

I’d like to clarify what you mean by “no issue” here. In general, I’d expect Wi-Fi to be slower than Ethernet, but it doesn’t seem like it’d be slow enough to mask this issue. So imagine these scenarios:

Server   | Network API | Speed
------   | ----------- | -----
Dispatch | Ethernet    | A
Dispatch | Wi-Fi       | B
Network  | Ethernet    | C
Network  | Wi-Fi       | D

In both servers I’d expect to see a slight performance loss from Ethernet to Wi-Fi, but it sounds like you’re seeing a much greater performance loss in the Network framework case. That is, the C:D ratio is wildly different than the A:B ratio.

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thank you for your quick answer.

You are correct, the issue is that the C:D ratio is wildly different than the A:B ratio.

To be more specific, below are the results we can see to download a 20MB file, depending on your cases above (A, B, C or D).

1. Server on macOS 26.1, or macOS 15.6.1

With TSO enabled:

A: Download time: 0.208543s, Bytes: 20971520, Speed: 100562090 bytes/sec
B: Download time: 0.638284s, Bytes: 20971520, Speed: 32856095 bytes/sec
C: Download time: 23.000043s, Bytes: 20971520, Speed: 911803 bytes/sec
D: Download time: 3.259781s, Bytes: 20971520, Speed: 6433413 bytes/sec

As you can see, with ethernet, a server in GCD takes less than 1 second to download a 20MB file, while with Network, it takes more than 20 seconds.

In Wifi, it's slightly better, but still slower than GCD.

With TSO disabled:

If on the server side, we disable TSO using sudo sysctl -w net.inet.tcp.tso=0

A: Download time: 0.208460s, Bytes: 20971520, Speed: 100602129 bytes/sec
B: Download time: 0.672691s, Bytes: 20971520, Speed: 31175562 bytes/sec
C: Download time: 1.865778s, Bytes: 20971520, Speed: 11240093 bytes/sec
D: Download time: 2.332780s, Bytes: 20971520, Speed: 8989926 bytes/sec

It is much better for case C.

2. Server on macOS 14.7

With TSO enabled:

A: Download time: 0.232860s, Bytes: 20971520, Speed: 90060637 bytes/sec
B: Download time: 0.680401s, Bytes: 20971520, Speed: 30822294 bytes/sec
C: Download time: 6.255250s, Bytes: 20971520, Speed: 3352626 bytes/sec
D: Download time: 7.912810s, Bytes: 20971520, Speed: 2650325 bytes/sec

A server using Network is still slowed than GCD, but it is much better than on macOS 26 and 15.

With TSO disabled:

A: Download time: 0.236461s, Bytes: 20971520, Speed: 88689128 bytes/sec
B: Download time: 0.707016s, Bytes: 20971520, Speed: 29662016 bytes/sec
C: Download time: 6.275888s, Bytes: 20971520, Speed: 3341602 bytes/sec
D: Download time: 6.758729s, Bytes: 20971520, Speed: 3102879 bytes/sec

Difference is marginal, so disabling TSO has no impact on macOS 14.7.

I hope it clears things up. Let me know if you need more info.

Pierre

Well, that’s weird. IMO you have more than enough evidence to justify a bug report about this. Regardless of whether I can help you improve things, Network framework should perform well out of the box on all link layers.

Please post your bug number when you’re done.

I suspect that this is fallout from the user-space networking stack. Once I’ve got your bug number, I’m going to use that to drive some more research at my end.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you Quinn.

I originally did file a bug report (Case-ID: 16602242), but was told to post on the forum instead. So I pinged back on the ticket to let them know.

One more thing that I've just learned from some of our customers:

• apparently there is no issue with macOS 15.3
• but there is with macOS 15.6.1

So it seems the issue started in between these versions, I'll try to find a way to install 15.4 and 15.5 and confirm in which of these versions it started.

Thank you again for your replies.

Pierre

I originally did file a bug report (Case-ID: 16602242)

Ah, you’re being confused by Apple’s many systems )-: The above is a DTS case number. I bounced you to the forums so that I could clarify the exact problem you’re seeing. I’m now suggesting that you file a bug report. You do that in Feedback Assistant. The resulting bug number will look like FBnnnnnnnn.

I have lots of details about how to file bug reports in Bug Reporting: How and Why?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Oh yes indeed it seems I got confused. It's usually my colleagues that submit bug reports...

It's now done, here is the bug report number: FB20871628

Thank you for the precision!

Pierre