This may be a dumb question, but I am still confused about it.
There are a few situations I've been looking into in regards to performance.
Comparing .NET Core vs .NET Framework
I've created two identical sample applications, except for one is .NET Framework 4.7.2, and the other is .NET Core. They both use HTTP/1.1 and the same initial extent.
Manual testing:
It feels like tiles take longer to complete drawing (DrawStatus.Complete) in the .NET Core application, compared to the one in .NET Framework, when zooming in and out in the same place.
Automated testing:
Both applications start working at the same time, and perform zoom in/out in tandem. Using this approach, the trend seems to be that the .NET Core usually takes longer, but I don't have definite proof, as they sometimes seem to change who takes the longest, based on stopwatch before performing SetViewpointScaleAsync, and DrawStatus.Complete. I don't know if the ServicePointManager.DefaultConnectionLimit Property (System.Net) | Microsoft Docs is affected across processes, and could have some sort of impact.
Tiles from cache
The real cause I noticed this, is the behavior in the attached animated GIF (hopefully it is displayed here). This is a rather large screen, which makes it more obvious. The tiles are loaded from cache, but the delay in drawing them is quite noticeable.
We are still evaluating whether to default to HTTP/2 or not. At this point we've decided to use the default version of .NET core and not explicitly set it. See https://github.com/dotnet/corefx/blob/release/3.0/src/System.Net.Http/src/System/Net/Http/HttpUtilities.cs#L17
As mentioned above our .NET Core support isn't fully finalized yet.
Wrt tile performance I'm not entirely following: Are you saying the behavior is different from .NET Framework? We shouldn't be making requests to the server again for the same tiles if the server said that the tiles can be cached.
Hi,
I quickly whipped up a sample project for .NET Core 3.0 final to look for performance improvements, and in particular in regards to HTTP/2. However, looking at my IIS server logs, I can see requests made from Chrome are logged with HTTP/2.0, but from the sample application they are logged as 1.1.
It appears that if I handle the ArcGISHttpClientHandler.HttpRequestBegin Event and assign e.Version = new Version(2,0), the requests is actually performed using HTTP/2. Shouldn't the Runtime use HTTP/2 by default without having to opt-in in this way, or is there something that I'm missing?
Looking at a performance, I notice an odd artifact when zooming in and out on the same spot (one delta of the wheel), while there are no requests being made to the server, there is a visual appearance of the tiles being loaded from server rather than quickly/instantly retrieved from the cache, which I find odd. I already have an intermittent dialog with Michael Branscomb on the performance topic, so I was wondering if this should be part of the direct dialog, or in the forums.
Just a follow-up to this: The just-released v100.6 has support for .NET Core 3.0 (as a preview). It will however only run on Windows, and will require the .NET Core 3.0 Desktop packages.
We hope to fully support it by Update 7 on top of .NET Core 3.1, but would love feedback now of anything that might not work as you intended.
At the devsummit we announced that we will be adding support for .NET Core 3.0 to the WPF SDK. Note though that this will be for Windows only, and will not support running it on other platforms .NET Core also runs on.
Timeline depends on when .NET Core 3.0 will finalize, which is currently is scheduled to be "second half of 2019" (see https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-3/ )
We'll need a little bit of time after that release to finalize testing and ensure we'll run great on .NET Core 3.0, so we'll support it in the release after that provided we have enough time for doing the testing (otherwise it'll be in a release following that).
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
