I wanted to share with you a strange situation we're seeing on a .net appmon site and hear your ideas.
We have a SoapUI client calling a wcf web service. soapUI shows overall timings which are a lot greater then seen in AppMon purepaths. After researching the data we're understanding the following things:
- First wcf request gets http 401 and returns to the client after a few milliseconds (for example 9)
- the second call is received after a while (about 2 seconds in one case) and takes some time (1.3 seconds at the same case)
However, SoapUI still shows it took ~5 seconds and even more.
Without AppMon the customer did his own tests and replaced one of the dll's used in this appPool. This has solved the problem for him. To try and see why we weren't able to see this problem, he left us the problematic dll on one machine, so we've instrumented all of its functions to see how many calls are done to it, though we thought this would not be the problem as the overall timing of the purepath was not matching the duration we've expected. Indeed we found that not many calls were done to this dll.
Any ideas and ways to try and figure out why on earth this dll replacement have solved the problem ?
Just for my understanding. Replacing that DLL improved Response Time? Or did replacing that DLL show more data in the PurePaths and the times matched?
If it is "improved response time" then it would be intersted what type of DLL it was. Was it a DLL loaded by the Application itself or was it an IIS Module? If it was an IIS module I can easily see how a DLL update can change behavior - especially when upgrading from a native to managed module. We currently dont see details of native IIS modules - so - this would explain why the PurePath might be shorter as we dont see that code execution.
Anyway - any more details you can share on "that DLL" would make it easier to come up with potential explanations!
Talked to the customer. It turned out that their service (.net), had some initialization code when the app pool was created that wrote to the web.config and caused another recycle of the pool. Since we are only seeing the requests, we could not see the initialization method. I guess we will need to add sensors on their initialization code.