Forum Discussion
Helper IISevere Gateway Performance Degradation & High CPU Post-Migration (ASYNC_NETWORK_IO Waits)
Hello everyone,
I am looking for some architectural and performance troubleshooting advice. Following a server migration on March 27, 2026, our On-Premises Data Gateway has experienced a massive and continuous spike in CPU usage and data processing duration. Standard refreshes are now taking twice as long to execute.
Environment & Architecture:
OS: Windows Server 2016 Standard.
Hardware: AMD EPYC 9274F 24-Core (30 logical processors), 192 GB RAM.
Co-hosted Services: The physical server hosts the Gateway, SQL Server 2019, and Remote Desktop sessions.
Storage Configuration: Drive I (4KB allocation size), Drives E and D (64KB allocation size). SQL Shared Memory protocol is ON.
Symptoms & Observations:
Gateway Logs: We are seeing AsyncOperationStreamingCancelledException errors related to the spooler (No more this error after tuning applied on 24 April).
SQL Server Waits: Running sp_WhoIsActive during Gateway execution shows a high volume of blocked sessions with ASYNC_NETWORK_IO wait types. This specifically impacts databases located on Drive D (logs on Drive E). Performance for a database located on Drive I remains completely normal.
OS Impact: RDP sessions for users on this server periodically become unresponsive due to the resource drain.
Troubleshooting Steps Taken: Prior to April 20, the Gateway ran on default settings with the Spooler and Mashup Cache located on Drive C. I have since applied the following tuning:
Settings from 20.04 to 24.04
Container Tuning - from 20.04 to 24.04: Enabled overrides and adjusted Mashup pool containers. Currently set to MashupDefaultPoolContainerMaxCount = 4 and MashupDefaultPoolContainerMaxWorkingSetInMB = 8192.
I/O Relocation: C drive
Streaming: Toggled StreamBeforeRequestCompletes to TRUE.
Memory Management: Reduced SQL Server max server memory to 140 GB
Settings from 24.04:- Container Tuning : Enabled overrides and adjusted Mashup pool containers. Currently set to MashupDefaultPoolContainerMaxCount = 12 and MashupDefaultPoolContainerMaxWorkingSetInMB = 4096.
I/O Relocation: Moved the SpoolerDirectory and Mashup Persistent Cache to Drive I to alleviate potential disk contention.
Streaming: Toggled StreamBeforeRequestCompletes to FALSE.
Memory Management: Reduced SQL Server max server memory to 135 GB
Current Status: These changes successfully reduced Gateway CPU usage and processing duration compared to the post-migration peak. However, performance is still significantly worse than it was before the migration.
Has anyone experienced similar ASYNC_NETWORK_IO bottlenecks between local SQL Server instances and the Gateway Mashup engine after hardware/server migrations?
Thank you in advance for your insights.
EDIT: 30.07.2026
Created new gateway (testGateway) on different VM. Moved couple of reports to new testGateway. The issue is still there. Performance seems bit better, but still there is ASYNC_NETWORK_IO bottleneck.
18 Replies
- lbendlin
Super User
Co-hosted Services: The physical server hosts the Gateway, SQL Server 2019, and Remote Desktop sessions.There's your problem, right there. You should never place any other process on a gateway VM, especially not a SQL Server. They will starve each other of resources.
Have you changed the MemoryUtilizationPercentageThreshold and/or CPUUtilizationPercentageThreshold parameters?
Is this a single VM or a cluster?
CatoDThank you for the answer. I'll bring the issue of the gateway and SQL Server on the same VM to the IT department.
I've changed CPUUtilizationPercentageThreshold to 80.
It is single VM.
- GilbertQ
Hi CatoD
It clearly appears that there are some settings that were different between the servers. Because you previously stated that a server was migrated, I would highly recommend comparing the differences between the two servers to ensure that they have the same settings. But as lbendlin Recommended. They should be on separate servers.
v-echaithraCommunity Support
Hi CatoD ,
We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if further assistance is still required. We are available to support you and are committed to helping you reach a resolution.
Thank you.- CatoD
The issue is not resolved yet. I'm in touch with my org IT department, to try to move gateway to separate VM.
- v-echaithra
Hi CatoD ,
Thank you for the update. Moving the Gateway to a dedicated VM is a good next step and should help determine whether the current bottleneck is caused by resource contention between Gateway, SQL Server, and RDP workloads.
Once the separation is completed, please monitor:
Gateway CPU and memory utilization
Refresh duration
SQL wait statistics, especially ASYNC_NETWORK_IO
Disk latency on the SQL data/log volumesIt would also be useful to compare the storage and SQL configuration between the old and migrated environments, since the issue started immediately after migration and only affects databases hosted on specific drives.
Thank you. - v-echaithra
Hi CatoD ,
We’d like to follow up regarding the recent concern. Kindly confirm whether the issue has been resolved, or if further assistance is still required, please provide sample pbix file. We are available to support you and are committed to helping you reach a resolution.
Thank you.- CatoD
Issue is not yet resolved. I'll post again, when it is.
Please do not spam the topic.
- v-echaithra
Hi CatoD ,
Understood, thank you for the clarification.We will wait for your next update once additional testing or infrastructure changes have been completed. Hopefully isolating the Gateway to a dedicated VM helps narrow down the root cause.
Thank you.
- v-echaithra
Hi CatoD ,
We wanted to kindly follow up regarding your query. If you need any further assistance, please reach out.
Thank you.- CatoD
As for now, I'm waiting for new VM on other hardware, for the on-premise gateway. The process will take about 2 weeks.
- v-echaithra
Hi CatoD ,
Thank you for confirming the update.
Please feel free to reach out once the new environment is ready or if you need any further assistance from our end in the meantime.
Thank you.
- CatoD
I got access to other VM, installed gateway there. After few days of testing, the performance results are almost the same. The problem with ASYNC_NETWORK_IO is still there.
- CatoD
Anyone with ideas what to check else?
- tayloramy
Hi CatoD,
When you are running your refresh, what is your gateway CPU and Memory usage at?
the network_io wait means that whatever application that is consuming the data (the gateway in this case) has not yet acknowledged that it has all the data. If the gateway is maxing out on it's resources, then everything will be slower.
Can you also confirm what version of SQL Server and what version of the gateway are in use?
- CatoD
Hey tayloramy,
Here are the charts with gateway CPU and Memory usage (the spikes are during refresh):
the network_io wait means that whatever application that is consuming the data (the gateway in this case) has not yet acknowledged that it has all the data. If the gateway is maxing out on it's resources, then everything will be slower.
Ok, got it. There was no problem on slower machine, so theoretically migrating to better one, should no degrade on performance couple times.
SQL Server version:Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) Sep 24 2019 13:48:23 Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2016 Standard 10.0 <X64> (Build 14393: ) (Hypervisor)
On-Premise gateway version (both machines):
3000.326.12
- lbendlin
How many NICs? At what speed?
- CatoD
Hi lbendlin ,
On sql machine there is 1 NIC:
Name InterfaceDescription Status LinkSpeed
---- -------------------- ------ ---------
Ethernet Red Hat VirtIO Ethernet Adapter Up 10 Gbps
On additional VM, there is also 1 NIC:Name InterfaceDescription Status LinkSpeed
---- -------------------- ------ --------- ----------
Ethernet 2 Red Hat VirtIO Ethernet Adapter Up 10 Gbps
