Support 'ServiceInterop' on linux?

[onionhammer]

Per this document https://docs.microsoft.com/en-us/azure/cosmos-db/sql/performance-tips-dotnet-sdk-v3-sql#hosting-recommendations, Windows x64 hosting to Linux or x86 hosting due to some component of the library not working on anything but x64 windows.

Is this limitation still present? If so will ever be rectified? When?

[j82w]

We are currently working on a few different optimizations, but we don't currently have a time frame on when it will be ready. There was work done to add a C# query parser that can skip getting the query plan for several scenarios so the service interop is no longer needed for those cases.

#1743 Query Performance: Adds skipping getting query plan for non-aggregate single partition queries on non-Windows x64 systems when FeedOptions.PartitionKey is set

What is your concern around not having the service interop? Are you detecting high latency or other issues with query?

[onionhammer]

@j82w thanks for getting back - yes my concern is latency, but it's difficult to measure. I'm wondering why the discrepancy exists. is it because Cosmos was originally developed for Windows servers and this is some native code that was split off the actual server-side code that can only run on windows? Why cant this component be made cross-platform and still native if need-be? It's a huge file (7mb), and I still seem to end up paying for this 7mb even on my linux servers

[j82w]

Yes, it's because Cosmos was originally developed for Windows servers. Modifying it to run on Linux would take a lot of work, and has a several issues where it does not handle all scenarios. I would also like to point out that the Java SDK do not use this dependency. There are plenty of large customers using those SDKs without any issues. What impact does the 7mb cause on the Linux servers?

[onionhammer]

It's just the single largest dll in my not-small web application by like 3x.

I see this breaking down in 1 of 2 ways:

A) Making that subset of functionality x-plat is worth it to save every query from an extra network roundtrip for every customer not running on Win x64.. OR

B) If this ServiceInterop dll is makes so little difference that other platforms dont miss it, remove that minor optimization for win x64 so everyone else isnt carrying around that extra weight; and insiginficant unimportant code doesnt need to be continually maintained

For Linux and other unsupported platforms where ServiceInterop.dll isn't available, an additional network call is made to the gateway to get the optimized query.

Is the timing of that extra network call logged?

[thuruaventude]

@kirankumarkolli : we have been observing this issue (and related ones). you have removed this from the Triage, does it mean waiting forever?

[onionhammer]

I would like an answer to the above question...

If this optimization so minor that other platforms don't miss it, then why does the optimization need to exist for a single platform (at the expense of all the others)?

If the optimization is NOT minor, then the other platforms ARE missing it, and it should be ported.

[onionhammer]

Any movement on this? Do any Cosmos customers benefit from a Windows-only, x64-only, .NET-sdk-only native dll which calculates the query plan in-process? Why not expand this capability to Linux (where the vast majority of servers & services run)?

Any updates / comments?