CloudKit Operation Speeds

If you're considering CloudKit as an alternative to your existing on-device database systems, then you are going to be disappointed. You are performing operations against a remote server, not a local disk.

As for whether 30 seconds is a typical operation completion time, it largely depends on the amount of data being transferred and the speed of the network.

For what it's worth, my typical operation times are meaningfully measured in 100's of milliseconds unless I'm transferring large CKAssets.

I understand that CloudKit will not replace my local persistance, but without the cloud capabilities, my application is almost pointless. Should I only rely on CloudKit to sync sometime during lifetime of the applicaiton, rather than exactly when I ask it to?

As for the speeds specifically, I am querying less than 5 objects each with a single String field. Result: 56 seconds.

56 seconds sounds awfully excessive for that amount of data.

I would run the requests through a debugging proxy such as Charles to verify exactly how long the network requests are taking.

@jwitcig is right. I'm experiencing the same thing too. I have a record type which only has 1 custom property and that one's type is CKAsset.

I've created a new record of that type and uploaded an asset of 365 KB and now when I try to fetch all the records of that type (which is only 1) using CKQueryOperation it takes > 30 seconds, but when I use a CKQueryOperation on a different record type which doesn't have any CKAsset properties then it's pretty fast.

I have since purchased a MacBook Pro, where development on the same projects running the same requests is operating at lightning speed. What could I have jacked up on my iMac to be causing this?

Having read the rest of the thread I see you've obtained a new system and it works fine there. You might want to check the type of connection you have between your test device and the machine. Did you use the same network/wifi setup in both environments? After that I would un-install and re-install XCode. If that doesn't do it then I'd do a re-install of the OS and see what that does. I worked with iCloud for our latest app and anything more than 5 seconds would be way out of line. In fact even that would be pusing it. Most often the first contact with the database was something less than two seconds and subsequent operations after that were measured in milliseconds.

As you've discovered the CKAsset type does take considerably longer than others, this is to be expected since it not only downloads the record but the file itself. Naturally your connection speed will have an effect and the overhead that XCode requires to track statement execution also affects the speed at which you will see things in the log. Word of warning, we encountered times when the file was not delivered along with the record. If the file was too big or the transmission took too long due to interference of some other kind (interruption in wifi), then the record would arrive but the file wouldn't be there. Avoid crash by verifying that CKAsset != nil.

Our app was rejected for not providing functionality without access to iCloud. Even though everything seems to be migrating to cloud based data storage, there is a requirement that the app provide functionality without it. We provided default data for everything in the app bundle, used local storage to cache data, all views used data from the local cache, and used iCloud + CloudKit to perform updates when connected.

HTH,

Mike

30 seconds for 365kb seems excessive to me too. I did a quick test of a file we have that's 127kb and it took only a two count to download. The test was on an iPhone 5c connected to Wifi on secure network @ 5ghz. The same file using cellular connection took a three count. (thousand-one, thousand-two very un-scientific 🙂 )

How are you determining the time that it's taking to download? Log entries written from the completion handler? What else is the app doing at the time? CloudKit is asynchronous so it might have to wait for other operations on the app's main thread to complete before it can fire the completion handler. Simplify the operations, perhaps in a test app, to eliminate all other outside forces and get a true reading of just that download.

HTH,

Mike

- Index - On the CloudKit Dashboard, add an index on the record type for the field you are querying on. See if the index improves query times.

- Quality of service - You can QOS on all operations (try userInteractive)

- Sync - To keep records in sync, Use CKFetchDatabaseChangesOperation, CKFetchRecordZoneChangesOperation

I'm not seeing long times. However, I'm seeing some records are not posting. I'm new to CloudKit, so I'm probably doing something wrong. However, if I'm doing something wrong, why are the records sometimes posting and sometimes not? Note that in the case where it doesn't post, I am getting a return record with a recordID when I call save. Also, I'm printing the result of the save only if error is nil. So why doesn't the record show up when I do a query using the CloudKit online query tool? It's not a problem with a filter I created, because I'm querying all records of the record type in question and clicking on the created field to sort the most recent to the top. Seems like if I got a record ID, it must have posted, but then why doesn't it show up?

Edit: never mind. I see now the issue is that the results in the dashboard are paged and that clicking a heading to sort the results sorts only that page of results. The records were there, just on a different page.