Member Avatar for Mike Askew
Mike Askew 131 Veteran Poster

Hi All

We are having an issue where a WSDL is loading another WSDL into it when we call it. This call takes a while on the first call which normally causes failures across the application during testing. One option we are looking into is pre-caching the WSDL in IIS prior to the server becoming available in the load balancer.

Does anybody have any knowledge around how WSDL caching behaves in IIS?

Couple of questions I am trying to figure out:
1) How long does a WSDL stay cached for once it is first called
2) Does IIS cache the WSDLs by default?

Cheers

Mike

  • 1 Contributor
  • 0 Replies
  • 329 Views

Dani AI

Generated

For — short, practical summary and actions.

IIS does not have a special, built‑in “WSDL cache” behavior. A WSDL served as a static .wsdl file is treated like any other static asset and obeys normal HTTP/client cache headers; a WSDL produced by an ASMX or WCF endpoint is generated on demand by the runtime (so IIS won’t magically keep it forever unless you configure caching). (learn.microsoft.com)

“How long” a WSDL stays cached depends entirely on which cache you mean and how it’s configured: client/proxy caching is controlled by HTTP headers (IIS’s <clientCache> settings); IIS output cache profiles control server/user/kernel caching and have explicit durations or “CacheUntilChange” policies (default profile duration is short unless changed); http.sys (kernel cache) also uses heuristics (“hotness”, scavenger intervals) and entry size limits. In short: there is no fixed WSDL TTL — it’s driven by cache config and http.sys heuristics. (learn.microsoft.com)

Recommended practical fixes (fastest, lowest‑risk first):

  • Warm the app and metadata before putting the box into the LB: enable Application Initialization / preload so IIS starts the worker and issues warm‑up requests (include the ?wsdl URL and any imported XSD/WSDL URLs). Example appcmd commands: 
appcmd set app "Default Web Site/MyService" /preloadEnabled:true
appcmd set apppool "MyServicePool" /startMode:AlwaysRunning

Application Initialization will let you target specific warm‑up URLs. (learn.microsoft.com)

  • If acceptable, serve a pre‑generated static WSDL (or point WCF’s <serviceMetadata externalMetadataLocation="..."> at a static file) so the WSDL is instant and easy to cache. (learn.microsoft.com)

  • Or configure IIS output caching to cache the metadata response (example: cache .svc responses for ?wsdl for a short duration or until change). Use <system.webServer><caching> profiles to control kernel/user caching and duration. (learn.microsoft.com)

Cautions & diagnostics: don’t cache metadata if it changes frequently or exposes sensitive internals; when debugging cache behavior use Failed Request Tracing (look for HTTPSYS_CACHEABLE reasons) and netsh http show cachestate url=... to inspect http.sys entries. Tweak http.sys cache limits / scavenger settings only if you understand memory impact. (blogs.iis.net)

Bottom line: the simplest reliable fix is to preload/warm the application and explicitly hit the ?wsdl (and its referenced imports) during initialization; if runtime generation is unacceptable, serve a static WSDL or add an IIS output cache rule for the metadata endpoint. (learn.microsoft.com)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.