I’ll address all three areas causing your API timeout issues under load.
API Gateway Timeout Configuration:
Your Azure Application Gateway has a 60-second backend timeout which is too aggressive for ECO creation operations. Increase this to at least 180 seconds (3 minutes) to accommodate the workflow initialization and database operations involved in ECO creation. In Azure Portal, go to Application Gateway > Settings > HTTP settings and modify the Request timeout value:
az network application-gateway http-settings update \
--gateway-name windchill-appgw \
--name windchill-http-settings \
--timeout 180
Also verify your API Management (if you’re using APIM in front of App Gateway) doesn’t have its own lower timeout. APIM default is 30 seconds which would cause failures before App Gateway timeout even kicks in.
Load Balancer Configuration for API Distribution:
Your load balancer needs proper session affinity and connection draining for API requests. ECO creation involves multiple internal API calls that benefit from session persistence. Configure cookie-based affinity in your Application Gateway backend settings. This ensures all related API calls for a single ECO creation go to the same backend server, reducing database lock contention and improving cache hit rates.
Also critical: Set your connection drain timeout to 120+ seconds. Without this, when the load balancer decides to shift traffic, it can terminate active API connections mid-request causing the 504 errors you’re seeing. Configure this in the backend pool settings.
For concurrent request handling, verify your Application Gateway SKU supports your load. Standard_v2 or WAF_v2 SKUs handle concurrency much better than older SKUs. Your 10 concurrent requests should be no problem, but if you’re on an older SKU, it might be queuing requests unnecessarily.
Backend Scaling and Resource Optimization:
While your CPU looks fine at 40-50%, ECO creation is database-intensive. Check these Windchill configuration parameters in your method server site.xconf:
wt.pom.dbcp.maxActive=100
wt.pom.dbcp.maxWait=30000
wt.method.server.maxThreads=150
The database connection pool (dbcp.maxActive) might be too small for 10 concurrent ECO creations across 3 servers. Each ECO creation uses 3-5 database connections during its lifecycle. With default settings of 50, you’re hitting pool exhaustion. Increase to 100 per server.
Also implement API request queuing in your integration service. Instead of sending 10 concurrent requests, use a queue with 3-4 worker threads. This prevents overwhelming the backend while still maintaining good throughput. ECO creation performance degrades non-linearly after about 5 concurrent operations due to database lock contention on workflow tables.
Monitoring and Validation:
Enable Application Insights or Azure Monitor to track actual request duration at each layer. You’ll likely find that requests aren’t actually taking 62 seconds in Windchill - they’re spending time queued at the load balancer or waiting for database connections. Set up alerts for backend response times exceeding 30 seconds so you can identify issues before they cause timeouts.
After implementing these changes, test with gradually increasing concurrency: 2, 4, 6, 8, 10 requests. You should see consistent 15-25 second response times across all concurrency levels with proper configuration.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.