URLSession + GCD - Best practices

I think you’re asking about how you should pass requests to

URLSession

rather than how you should process the response completion handlers. In that case my general advice is that you need to give

URLSession

enough requests to make sure it can keep the wire ‘busy’. The minimum value for that really depends on your requests:

• Are they all going to one server? Or spread across multiple servers?

• Are they bulk uploads or downloads? Or small interactive requests?

• Does the server respond to the request immediately? Or take its time ‘chewing’ on the data?

• Are all the requests of equal priority? Or do you get high-priority requests that you want to be serviced quickly?

The maximum value is typically around a couple of hundred. You can pour a few requests into any given session and it’ll cope just fine. Once the number starts getting bigger than that you need to think about scheduling your requests outside of the session.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 5 Jun through to Fri, 9 Jun. During that time all of DTS will be at the conference, helping folks out face-to-face. http://developer.apple.com/wwdc/

Sorry to resurrect this old post, but I have two follow-up questions for you, Quinn:

1. You mention that the max value (number of requests) is typically around a couple hundred; what happens if you go over that?

2. Do you have recommendations for how to schedule requests outside of the session? NSOperationQueue and NSOperation subclasses?

what happens if you go over that?

It depends. I’ve seen folks pour thousands of requests into a background session and that can cause weird issues with the daemon that runs background sessions (nsurlsessiond). However, for standard sessions this sort of thing generally doesn’t cause too much grief.

Do you have recommendations for how to schedule requests outside of
the session?

Once you start generating large numbers of requests, you have to start thinking about where those requests stack up. Stacking up unbounded amount of work on an NSURLSession is bad, but it’s also bad to stack up unbounded amounts of work on a dispatch queue. What you need is flow control, that is, preventing the source from generating new requests until the system has had a chance to process some of the requests that are in flight. And how you do that really depends on the nature of the thing generating the requests.

So, where are all these requests coming from?

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

Thanks for the response!

Once you start generating large numbers of requests, you have to start thinking about where those requests stack up. Stacking up unbounded amount of work on an NSURLSession is bad, but it’s also bad to stack up unbounded amounts of work on a dispatch queue. What you need is flow control, that is, preventing the source from generating new requests until the system has had a chance to process some of the requests that are in flight. And how you do that really depends on the nature of the thing generating the requests.

So, where are all these requests coming from?

I'm working on the networking stack for a large app built by a large development team. In answer to your question, the requests come from all over the place — in response to user events, as periodic "make sure we're up-to-date" events, in response to push notifications, etc. I don't think we'll have anywhere near the level of thousands of requests being enqueued or in-flight at a time; I would think it's more on the order of a dozen or two, max.

I would think it's more on the order of a dozen or two, max.

In that case I think it’s fine to just drop them all on the session and let it sort them out.

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