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.