Optionally Turn off Kiota Backing Store

[grippstick]

Is your feature request related to a problem? Please describe the problem.

When I download a very large Attachment, where the contentBytes are included, it is extremely slow, because of the Kiota Parsing.

Describe the solution you'd like.

I would like a way to tell the GraphClient to do a fast Deserialize that is not tracked.

Maybe something like
graphClient.Me.Messages[msgID].Attachments[attID].GetAsync(config => {config.DoNotTrack();})

Additional context?

No response

[baywet]

Hi @grippstick
Thank you for using the SDK and for reaching out.
Can you please provide more information?

• What times are you seeing?
• Have you tried unselecting the content bytes property if you don't need it?
• How is the parsing problem related to the backing store itself in your view?

[grippstick]

The problem is that I actually need the content bytes, but I do not need their change history tracked by the backing store. My work around has been to make direct http calls to the endpoint and then deserialize myself. I would love to use the SDK for this task, but the backing store is a bottleneck. On large payloads it is extremely slow and causes intermittent stackoverflow exceptions, when used in multiple threads. I have opened another ticker here: #2588 I have isolated it to the backing store by stepping through the code and seeing that it is trying to track every byte, which does not perform well with a 20Mb attachment. My use cases do not require me to send back patches or changes. I am downloading and storing.

…

On Mon, Aug 12, 2024 at 8:18 AM Vincent Biret ***@***.***> wrote: Hi @grippstick <https://github.com/grippstick> Thank you for using the SDK and for reaching out. Can you please provide more information? - What times are you seeing? - Have you tried unselecting the content bytes property if you don't need it? - How is the parsing problem related to the backing store itself in your view? — Reply to this email directly, view it on GitHub <#2563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBPTOUIAQI7HLUBDF6ECLLZRCYY5AVCNFSM6AAAAABJ6FKRWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTHE3DMMBUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Joshua

[baywet]

Thank you for the additional information.

I have isolated it to the backing store by stepping through the code and seeing that it is trying to track every byte, which does not perform well with a 20Mb attachment.

Can you provide more context on this please? Or even a reproduction of the issue isolated from any network call if possible.

[grippstick]

I am not sure how to isolate this from a network call. I do not know how to recreate the response and get it to deserialize. I do know that if I use the same message attachment: Ihis call takes roughly 7 seconds to complete: ```csharp await graphClient.Me .Messages[msgID] .Attachments[attID] .GetAsync(config => { config.WithImmutableId(); }).ConfigureAwait(false); ; ``` This call uses a native request and then deserializes with System.Text.Json. It takes roughly 1.5 seconds in total to download and parse. ```csharp using (var httpRequest = await graphClient.RequestAdapter.ConvertToNativeRequestAsync<System.Net.Http.HttpRequestMessage>(requestInformation).ConfigureAwait(false)) { using (var httpResponse = await MicrosoftGraphHelper.MsGraphHttpClient.SendAsync(httpRequest).ConfigureAwait(false)) { if (httpResponse.StatusCode == System.Net.HttpStatusCode.NotFound) { //if this was not found, we should just reschedule and come back later throw new AsyncProcessor.AsyncProcessorRescheduleException("This attachment was not found, let's reschedule for later.", 2); } httpResponse.EnsureSuccessStatusCode(); var responseString = await httpResponse.Content.ReadAsStringAsync().ConfigureAwait(false); var json = System.Text.Json.JsonDocument.Parse(responseString); return new FileAttachment { ID = json.RootElement.GetProperty("id").ToString(), Name = json.RootElement.GetProperty("name").ToString(), ContentByteString = json.RootElement.GetProperty("contentBytes").GetString() }; } } ``` The majority of the time for the request that uses kiota spends its time in this below function enumerating over each byte in contentBytes: InMemoryBackingStore.cs ```csharp private void EnsureCollectionPropertyIsConsistent(string key, object? storeItem) { if(storeItem is Tuple<ICollection, int> collectionTuple) // check if we put in a collection annotated with the size { // Call Get<>() on nested properties so that this method may be called recursively to ensure collections are consistent foreach(var item in collectionTuple.Item1) { if(item is IBackedModel store) { foreach(var innerItem in store.BackingStore.Enumerate()) { store.BackingStore.Get<object>(innerItem.Key); } } } if(collectionTuple.Item2 != collectionTuple.Item1.Count) // and the size has changed since we last updated) { Set(key, collectionTuple.Item1); //ensure the store is notified the collection property is "dirty" } } else if(storeItem is IBackedModel backedModel) { // Call Get<>() on nested properties so that this method may be called recursively to ensure collections are consistent foreach(var item in backedModel.BackingStore.Enumerate()) { backedModel.BackingStore.Get<object>(item.Key); } } } ```

[grippstick]

I think I have a better view coming from the CPU Profiler [image: image.png] [image: image.png]

…

On Mon, Aug 12, 2024 at 9:43 AM Vincent Biret ***@***.***> wrote: Thank you for the additional information. I have isolated it to the backing store by stepping through the code and seeing that it is trying to track every byte, which does not perform well with a 20Mb attachment. Can you provide more context on this please? Or even a reproduction of the issue isolated from any network call if possible. — Reply to this email directly, view it on GitHub <#2563 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBPTOWJ3OAE47FW37ZFBN3ZRDCXXAVCNFSM6AAAAABJ6FKRWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBUGE3TKOBZGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Joshua

[baywet]

Thank you for the additional information.
You'll need to login to the GitHub web interface as the screenshots didn't make it through with the email.

[grippstick]

[baywet]

Thank you for the additional information.
I was able to isolate the issue and put a pull request together to address it.
microsoft/kiota-dotnet#326

[grippstick]

I can confirm that it is much faster than it was, but it is still very slow with the parsing.

This call has gone from 7 seconds to 3.5 seconds.

await graphClient.Me
                                         .Messages[msgID]
                                         .Attachments[attID]
                                         .GetAsync(config =>
                                         {
                                             config.WithImmutableId();
                                         }).ConfigureAwait(false); 

A direct call to MsGraphHttpClient.SendAsync(httpRequest)
takes 1.5 seconds, then it parses in <30ms.

I can see that the network portion of this is about 1.5 seconds, which means kiota is still taking 2 seconds to parse contentBytes.

Doing another cpu profile I can see that the majority of the slowness is coming from InMemoryBackingStore.Set, because it is still looping through every byte of the contentBytes.

[baywet]

Thanks for the follow up here, authored microsoft/kiota-dotnet#328 to address this additional issue.