Anyone else seeing unstable or slow communication between client → proxy → XMPie uStore?

[Magnus Byrkjeland]

Hi everyone,

We’ve been struggling with performance and connection issues in our XMPie uStore setup, and I’m trying to find out if others have seen similar behavior. I made a thread about this in June 2024, but the issues are now far more severe.

I have been investigating for weeks, so I'll try to give an overview below.

Setup overview
Our traffic goes through this chain, and I understand it is a normal setup recommended by XMPie:
Client → Proxy (Helicon ISAPI_Rewrite3 on Windows Server 2012 R2) → XMPie uStore Server (hosted at a data center in central Norway on Windows Server 2022).
Both servers have 1+ Gb connectivity. We have more than enough computational power.
I'll categorize traffic to our stores as moderate.

What we’re seeing

• Pages can be very slow to load or fail completely when accessed through the public domain.

• It happens much more often on mobile networks, but we also get complaints from clients on wired connections.

• When I connect directly to the uStore server via local IP (for example over VPN), performance feels normal and stable.

• Proxy logs show random long response times and sc-win32-status=121 errors (semaphore timeout).

• Event Viewer reports many SChannel TLS errors (“fatal alert 10, error state 1203”, "fatal alert 40,...", and other issues covering incompatibility between client & proxy on basically all ciphers).

• Simple bot or crawler requests sometimes take seconds to complete, even when serving static files (robots.txt).

• XMPie logs, however, also show slow responses on some asset requests — particularly ImageProxy, checkout/cart pages, and even login (uStoreAdmin) — so the delay isn’t only on the proxy. Though the XMPie logs are far more difficult to analyze.

What I’ve done to investigate

• Collected and compared IIS logs from both the proxy and the XMPie servers.

• Correlated requests across both tiers in a Jupyter Notebook to see where the bottleneck occurs.

• Found that when requests are slow, both proxy and XMPie record the same timestamps and status codes, suggesting upstream (XMPie) latency for many cases.

• In some isolated tests, though, the proxy hangs for ~20 s while the XMPie side responds normally.

• Ran an nmap TLS scan: the proxy still offers SSLv3, TLS 1.0/1.1, got warning for some weak ciphers, which could explain some handshake failures.

Summary of findings so far

• Both the proxy and XMPie servers show slow or failed requests at times.

• Proxy side: unexplained 121 timeouts, TLS alert 10 & 40 handshake failures, and slow responses even to small static files.

• XMPie side: certain endpoints (ImageProxy, cart, login, checkout) frequently take 8–20 seconds and occasionally return 500 errors.

• Issues are much worse for users on mobile carriers.

What I’m hoping to learn from the Community
Has anyone else experienced similar loading-time issues or unstable communication between the client, proxy, and XMPie servers?
Did any configuration updates, TLS settings, or proxy changes help in your environment?

Any experiences or knowledge about Windows Server, Server Security and Helicon Proxy would be greatly appreciated. Obviously, the TLS handshake errors contribute to the performance issues, but I need some more eyes on the problem as I am afraid I have become blind-sighted for other issues.

Thanks,
Magnus

[SteveL]

Hi Magnus,

Just my 2 cents...

Log a support case with XMPie Support.

Upgrade the Proxy OS to match the OS of the other servers in the XMPie group (I assume it is a SOLO server running Windows Server 2022, so upgrade the proxy OS to 2022).

Make sure you're on the latest versions of the XMPie software.

I hope you get to the root cause of the problem soon.

Steve

[Magnus Byrkjeland]

Thank you for the response.
I have a running case with XMPie support.
Correct, they run independently - we will upgrade the proxy version to 2022 as soon as possible.

Magnus

[markb]

Only thing I can think of is perhaps around SSL certs. I manage this manually for uStore (we only have one domain for all stores) by updating Proxy with the SSL, then export SSL from Proxy and then import to Base. Also, we trimmed down ciphers using https://www.nartac.com/Products/IISCrypto for PCI scans.

[Magnus Byrkjeland]

I see. Thank you for the comment.
I have tried trimming down ciphers with that tool - it did not do anything noticeable.
I managed to configure an experimental nginx proxy server running beside IIS on another port, written specifically for a single testing store.
It fixed the problem I am experiencing for that store - even running smoothly after adjusting the TLS configuration to the exact same configuration as the IIS proxy.
It points to the problem being somewhere in the configuration with IIS or HELICON.
We are setting up a completely new proxy server - hopefully that fixes our problem.