Have you ever seen that MSCRM SWS calls are being slow in some environments than others while using the same kind of hardware configuration? As a consequence, you may have seen migration applications where you are using SDK to create records, taking much more time in some configurations to upload the same data.
I have seen this kind of varying throughput in SWS calls in some of the lab environments. In fact, the SDK Account creation throughput varied from 25 to 48 records per second on same environment configurations. After investigations, I found that this difference was result of improper proxy settings in the client machine (the machine from where the SWS call is performed). This caused more processing in client side and time taking resolutions during SWS calls, degrading the overall throughput.
Let us have a closer look on how proxy settings work during remote calls. A proxy server sits between a client application (Web browsers, Chat clients or .NET applications) and the actual target server. When a computer is in a LAN, it can use a proxy server to connect to the Internet. In this case, the proxy server is combined with or is a part of the gateway server and firewall server. The proxy can cache web requests and serve multiple client requests with its cached data. If the requested data is not present in proxy server’s cache, then it forwards the request to the actual server, using its own IP address. Here, the proxy server acts on behalf of the client machine.
Though proxy servers can act as a cache server and help loading a web page faster, they can sometimes degrade performance if used improperly. Often people avoid manual proxy configuration and use automatic proxy configuration. Of course this helps in load balancing the proxy servers and avoids manual proxy configuration, but depending on the complexity of the configuration script, a significant delay can be experienced when using automatic proxy configuration.
Both these options look for a script file and use that to determine whether to use a proxy server or not. If yes then it finds which proxy should be used for a specific host and url. As a result, they add some amount of delay in processing a request.
On the other hand, if user selects a specific proxy server, then always the specific proxy server will be used and the overhead of locating, downloading and running the script file can be avoided. Moreover, if there are multiple proxy servers available in the LAN, the one which is geographically closest to the client machine, should be selected.
When MSCRM is installed on premise, inside a LAN, we can totally bypass the proxy server to achieve much higher throughput. The CRM server, being present inside the LAN, offers a local web address which does not require any proxy to be reached. The user can select bypass proxy server for local addresses and provide the fully qualified domain name of the CRM server in the exceptions (under Advanced tab) list. This gives better throughput when records are created using MSCRM SDK.
For Example, when I tried to create Accounts in a specific environment using ‘Automatically detect settings’, I could create only 25 records per second. When I switched to a specific proxy server, I was able to create 48 records per second in the same environment.
So if you experience slower rate of SWS calls in your environment, you may like to check whether your proxy is configured properly. Most of the times, it can improve SWS performance and help in faster data upload into MSCRM.
To know more about proxy configuration, you may like to read these:
Is this discussion germane to the BizTalk 2006 CRM Adapter (which uses the web services)? if so, what needs to be modified? Does it matter if the when the client computer is a server located on the same LAN subnet as the CRM web services?
This is germane to any application which uses MSCRM web services and is situated in the same LAN. So, if you have the BTS adapter computer and the CRM web server in the same LAN, you can try this settings. If your automatic proxy detection is indeed fast enough, then you may not experience the improvement. Whereas if the LAN is big and having multiple proxy servers with complex proxy determination scripts, you may experience throughput enhancement.
Only .NET 2.0 SOAP classes are capable of performing dynamic proxy discovery script evaluation (which is very slow/expensive, because it results in IL code generation).
So if you generate a .NET 1.1 SOAP proxy to connect to CRM 3.0 (which you should since CRM 3.0 is based on .NET 1.1), you may in fact not incur any penalty. On the other hand, your proxy will not be discovered as expected, forcing you to resort to other techniques.
Here is the relevant quote from MSDN:
"One of the issues in the .NET Framework 1.1 proxy support is that when the registry is read, the automatic configuration part of the proxy settings is ignored. Only the static portion of the proxy settings are read."
This is observed with .NET framework 2.0 SOAP proxy.
This is experienced with .NET 2.0 SOAP proxy.