-
Notifications
You must be signed in to change notification settings - Fork 387
Description
Hi team,
I've been using the CupertinoHttpClient in my app due to issues with bad file descriptors on the Dart client. However, I've encountered a persistent issue that makes it unusable in high-throughput media upload scenarios.
The error I frequently see is:
ClientException: The network connection was lost., uri=https://storage.googleapis.com/upload/storage/v1/b/...
Scenario
My app is media-driven, and users upload a large volume of images and videos daily. During profiling in a sandbox environment, I noticed this error consistently appears when uploading large media files in 8MB chunks and the ram usage spikes to the top. https://cloud.google.com/storage/docs/performing-resumable-uploads#chunked-upload
Specifically, I was uploading 80 video files (average size ~250MB each), with 8 uploads concurrently. These uploads are chunked in 8MB parts.
Investigation
Digging into the CupertinoHttpClient internals, I suspect the issue stems from overhead in transforming Dart byte arrays into NSData:
urlRequest.httpBody = request.bodyBytes.toNSData();
This conversion appears to cause significant memory pressure during high-volume transfers, likely contributing to dropped connections on iOS.
Outcome
Due to this limitation, I’ve decided to roll back to the default HttpClient, which, despite the file descriptor concerns, has proven more stable under these conditions.
Request
If possible, I’d love to hear your thoughts on:
Whether this NSData conversion could be optimized in this context, not sure is possible to share this pointer at the memory to Swift through ByteData.
Any recommended alternatives for media-heavy apps targeting iOS?
If there's any plan to improve CupertinoHttpClient support for large concurrent uploads.
Thanks for your work on the package, and let me know if more logs or reproduction steps would help.