Profiling in-process WCF calls
Jonas
Posts: 3
Hi,
We've been profiling our WCF-services in a number of ways and are struggeling with how to interpret results.
Initially we had Ants launch NUnit external GUI and ran our system tests. In the tests, we start the services from within NUnit. Thereby they are in the same process as NUnit and we get a profiling result from WCF-proxy down to datalayer. However, the results were quite shocking - the WCF overhead was huge. I.e. the call on the WCF-proxy was 5-10 times longer than the actual delay for the underlying methods, where we'd expected the DB-call to be the bottleneck.
We've tried the MS dual core hot-fix, but with no improvement.
Then we profiled a client which was calling the same interface, of a manually started host, and the result was quite different - the WCF overhead was reasonable. But when we had the client start the services in the same way as the tests, we got the overhead back. Code was running significantly slower, and Ants did not compensate accurately.
We've also profiled by plain old tracing to confirm that we don't have this overhead in reality.
Is this a known issue? Any idea what we could be doing wrong? It would be a huge benefit if we could use existing tests in initial optimizations.
Best regards
/Jonas Karlsson
We've been profiling our WCF-services in a number of ways and are struggeling with how to interpret results.
Initially we had Ants launch NUnit external GUI and ran our system tests. In the tests, we start the services from within NUnit. Thereby they are in the same process as NUnit and we get a profiling result from WCF-proxy down to datalayer. However, the results were quite shocking - the WCF overhead was huge. I.e. the call on the WCF-proxy was 5-10 times longer than the actual delay for the underlying methods, where we'd expected the DB-call to be the bottleneck.
We've tried the MS dual core hot-fix, but with no improvement.
Then we profiled a client which was calling the same interface, of a manually started host, and the result was quite different - the WCF overhead was reasonable. But when we had the client start the services in the same way as the tests, we got the overhead back. Code was running significantly slower, and Ants did not compensate accurately.
We've also profiled by plain old tracing to confirm that we don't have this overhead in reality.
Is this a known issue? Any idea what we could be doing wrong? It would be a huge benefit if we could use existing tests in initial optimizations.
Best regards
/Jonas Karlsson
Comments
My understanding is that WCF may be implemented in a way that uses heavy recursion or relies on JIT optimizations. You may want to try the beta of Profiler 4, which has reduced the effect of some of these legacy problems from ANTS Profiler 3.
Please see the ANTS Profiler 4 Beta Forum for more information.