流请求上传在iOS背景会话中从iOS 15.x上传速度缓慢

发布于 2025-02-10 23:52:09 字数 2905 浏览 3 评论 0原文

我正在使用使用iOS nsurlsession背景会话将数据上传到S3服务器的应用程序。从iOS 15.x中,我们观察到传输速度变得太慢(〜10 kbps)。

以下是配置,我正在

  1. 使用 backgroundSessionsconfiguration withIdentifier
  2. 设置
  3. set
  4. set
  5. “ nofollow noreferrer”>
  6. set a href =“ https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/3362533-TLSMINMIMSUPPERTEDPROTOCOLODI” >
  7. 创建nsurlsession使用
  8. uploadtaskwithrequest

当我用ipados 我测试了ipados 性能没有降解,但是使用iPados 15.3.115.5,我可以看到性能退化(上传速度慢了6倍)。

当我使用

对于所有测试,我将应用程序仅保留在前景

我的查询很少:

  1. iOS 15.x以上的背景会话配置有任何变化吗?
  2. 我们目前正在使用“ noreflow noreferrer“ Should we consider moving to background tasks introduced在iOS 13中?
  3. 是否可以通过OS(在这种情况下ios)来安排请求,并且我们(客户端)对传输速度没有或很少的控制?

ps: iOS模拟器也发生了降解。 在模拟器的情况下,它以某种方式取决于MacOS版本(从我的测试中可以看出)。

在Macos 12.4上,在Xcode 中13.2,ios 12.x13.x14。 x15.x模拟器正在显示性能退化。 当Macos 11.4中编译相同的应用14.x不是显示任何性能降解。

任何投入都将不胜感激。

I am working on an app which uses iOS NSURLSession background session to upload the data to the S3 server. From iOS 15.x, We have observed that transfer speed has become too slow (~10 kbps).

Following is the configuration, I am using

  1. Create the NSURLSessionConfiguration using backgroundSessionConfigurationWithIdentifier
  2. Set HTTPMaximumConnectionsPerHost to 8
  3. Set timeoutIntervalForRequest to 60s
  4. Set timeoutIntervalForResource to 86400s (1 Day)
  5. Set discretionary to false
  6. Set TLSMinimumSupportedProtocolVersion to tls_protocol_version_TLSv12
  7. Create the NSURLSession using sessionWithConfiguration
  8. send request using uploadTaskWithRequest

When I tested with iPadOs 14.8.1, there is no degradation in performance, but with iPadOs 15.3.1 and 15.5, I can see the performance degradation (uploads getting 6x slow).

When I create the session using ephemeralSessionConfiguration upload is very fast and there is no degradation (working as before).

For all the tests, I am keeping the app in foreground only.

I have few queries:

  1. Is there any changes in background session configuration for iOS 15.x and greater ?
  2. We are currently using backgroundSessionConfigurationWithIdentifier to create background sessions. Should we consider moving to background tasks introduced in iOS 13 ?
  3. Is it upto the OS (in this case iOS) to schedule the requests and we (clients) has no or very little control over the transfer speeds ?

PS: The degradation is happening with iOS simulators also.
In case of simulators, somehow it is dependent on macOs versions (as seen from my tests).

On macOs 12.4, in xCode 13.2, iOS 12.x, 13.x, 14.x, 15.x simulators are showing the performance degradation.
When the same app is compiled from macOs 11.4, xCode 12.4, iOS 12.x, 13.x, 14.x are not showing any performance degradation.

Any inputs would be highly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不喜欢何必死缠烂打 2025-02-17 23:52:10

我本人在为这个问题上挣扎之后,我想分享解决方案 - 对于其他人,以及我再次遇到此问题并不可避免地会忘记:修复使用背景会话配置上传的慢速下载速度,请确保您配置请求的网络服务类型 - 此设置对我有用:

var request = URLRequest(...)
// configure request
request.networkServiceType = .responsiveData

.Responsiveav也对我有用。请确保您仅在及时上传的方式进行上传时才设置此问题 - 如果它并不重要的话,只需使用适当配置的超时将其移交给背景会话,然后让它继续进行。

注意:只有在应用程序在前景中启动的上传任务时,这才会产生影响。如果上传任务在应用程序已经在后台时开始(例如,您需要先在某些扩展的背景执行时间内首先执行其他工作,然后恢复上传任务),则它将忽略此操作,并且表现得像您已经设置了一样。它是.background,它的速度像以前一样慢,就像在后台开始的请求一样大。

Having struggled with this problem myself, I wanted to share the solution - for others, and also for future me when I run into this again and inevitably forget: to fix slow download speeds for uploads using a background session configuration, make sure you configure the request's network service type - this setting works for me:

var request = URLRequest(...)
// configure request
request.networkServiceType = .responsiveData

.responsiveAV also worked for me. Do make sure you are only setting this if it is important that uploads happen in a timely manner - if it isn't important just hand it off to the background session with an appropriately configured timeout and let it get on with it.

Note: this will only have an impact if the upload task is started while the app in the foreground. If the upload task begins when the app is already in the background (for example, you need to do some other work first with some extended background execution time and then resume the upload task) then it will ignore this and behave as if you had set it to .background which will be as slow as before as requests started in the background are heavily throttled.

谁对谁错谁最难过 2025-02-17 23:52:10

模拟器可能只是将请求直接传递到MacOS上的Nsurlsession,因此模拟器行为将与MacOS版本一致是有道理的。

这听起来像MacOS 12和iOS 15中的性能回归。如果还没有,请用反馈助手提交错误,并附加最低可重复的样本。

在我的头顶上,我想不出任何原因,您会看到短暂的和背景会话之间可衡量的性能差异,除非处理外的助手的优先级过低。

背景任务和背景下载有些正交。前者正在您的应用程序中运行进程,因此,如果您的应用程序崩溃,则会失败。后者在单独的过程中运行,因此它们独立于您的应用程序是否正在运行。背景下载更适合大量下载,尤其是如果您的应用程序很大,因为这意味着iOS可以在不终止下载的情况下驱逐您的应用程序。

另一个明显的问题是,您是否在后台开始任务(例如响应完成另一个任务的完成)。后者可能会被限制,尤其是如果您在背景上传或下载完成后开始新的转移。您可以通过组合资源并将其上传到一个斑点(例如邮政编码)来避免罚款。我从您的问题中假设您不是,但我只是想确定。 :-)

我还假设这要么超过Wi-Fi,要么是网络不合时宜的,因为您还可以在MacOS上看到它。

最后,我假设这不是HTTP/3(QUIC)问题。当然,这就是iOS 15和MacOS 12中Nsurlsession的最大变化,因此,如果我指着手指,那将是我的第一个嫌疑人。

我不知道一种或另一种方式,但是我可以很容易地看到苹果决定禁用该功能的短暂会议,因为避免存储cookie等可能是微不足道的。平行线。

如果是问题,您可能会看到是否有某种方法可以在服务器端或客户端端禁用该功能。不过,我不知道有一种方法可以从我的头顶上做到这一点。

The simulator likely just passes the requests straight through to NSURLSession on macOS, so it makes sense that the simulator behavior would coincide with the macOS version.

This sounds like a performance regression in macOS 12 and iOS 15. Please file a bug with Feedback Assistant if you haven't already, and attach a minimum reproducible sample.

Off the top of my head, I can't think of any reason you'd see a measurable performance difference between an ephemeral and background session unless the out-of-process helper is running at too low a priority.

Background tasks and background downloads are somewhat orthogonal. The former are running in-process in your app, so if your app crashes, they fail. The latter run in a separate process, so they are independent of whether your app is running. Background downloads are more appropriate for large downloads, particularly if your app is large-ish, because it means that iOS can evict your app without terminating the download.

The other obvious question is whether you're ever starting a task while in the background (e.g. in response to completion of another task). The latter are likely to be throttled, particularly if you start a new transfer after a background upload or download finishes. You can avoid that penalty by combining resources and uploading them in a single blob (e.g. a zip file). I'm assuming from your question that you are not, but I just wanted to be certain. :-)

I'm also assuming that this is either over Wi-Fi or is network-agnostic, given that you also see it on macOS.

Finally, I'm assuming that this isn't an HTTP/3 (QUIC) issue. That is, of course, the biggest change in NSURLSession in iOS 15 and macOS 12, so if I were pointing fingers, that would be my first suspect.

I have no knowledge one way or the other, but I could easily see Apple decide to disable that feature for ephemeral sessions, because it may or may not be trivial to avoid storing cookies, etc. when you are reusing connections and making multiple requests in parallel.

If that's the issue, you might see if there's some way to disable that feature either on the server end or the client end. I don't know of a way to do so off the top of my head, though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文