Home/ Questions/Q 829213
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T03:50:48+00:00

For historical reasons, I have some WSE 3.0 web services that I cannot upgrade

  • 0

For historical reasons, I have some WSE 3.0 web services that I cannot upgrade to WCF on the server side yet (it is also a substantial amount of work to do so).

These web services are being used for file transfers from client to server, using MTOM encoding. This can also not be changed in the short term, for reasons of compatibility. Secondly, they are being called from both Java and .NET, and therefore need to be cross-platform, hence MTOM.

How it works is that an “upload” WebMethod is called by the client, sending up a chunk of data at a time, since files being transferred could potentially be gigabytes in size.

However, due to not being able to control parts of the stack before the WebMethod is invoked, I cannot control the memory usage patterns of the web service.

The problem I am running into is for file sizes from 50MB or so onwards, performance is absolutely killed because of GC, since it appears that WSE 3.0 buffers each chunk received from the client in a new byte[] array, and by the time we’ve done 50MB we’re spending 20-30% of time doing GC.

I’ve played with various chunk sizes, from 16k to 2MB, with no real great difference in results.

Smaller chunks are killed by the latency involved with round-tripping, and larger chunks just postpone the slowdown until GC kicks in.

Any bright ideas on cutting down on the garbage created by WSE? Can I plug into the pipeline somehow and jury-rig something that has access to the client’s request stream and streams it to the WebMethod?

I’m aware that it is possible to “stream” responses to the client using WSE (albeit very ugly), but this problem is with requests from the client.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are done. Gigabyte transfer and WSE 3.0 never worked together – you basically NEED streaming in WCF for that.

    You can just try to go 64 bit with the process and load up tons of memory so that the GC is not so much an issue. Upgrade to .NET 4.0 (should be painless mostly) and use the non-blocking GC. Hit the process with 12-30gb memory and you should survive a little more.

    Historically all ASP (.net) stuff is “batched”, first colecting all data then sending it. THis means large items just are not handled too well.

    • 0