Open Source Performance Monitoring Tools and Tricks for JavaSpeaker: Matt Secoske (07/28/2006)
Download presentation filesSpeaker: Christopher Browne (07/27/2006)
Download presentation files
The main problem with performance when using the APIs provided by ASPs is the per-call overhead. The overhead comes from latency over the Internet, transmission time, marshalling (xml/SOAP) requests on the client side and responses on the ASP side, un-marshalling (xml/SOAP) requests on the ASP side and responses on the client side, and authentication/authorization checking and other overhead at the ASP.
In accessing Salesforce.com and CRM OnDemand (both of these ASPs are located in North America, as are we), we have observed round-trip latency of 25 to 50 milliseconds. To get an estimate of the amount of per-call overhead, we did some tests with Salesforce.com by issuing an API call that returns the server time in GMT (Greenwich Mean Time). The fastest time that we got for completing this call was 150 milliseconds. Because the request and response are very simple (small) for this particular call, the transmission time and marshalling and un-marshalling times are very small contributors to the total call time. Furthermore, the actual processing time should also be very small since this is returning the server time in GMT (and hence no time-zone conversions are likely being done). This means that the per-call overhead is as much as 150 milliseconds including latency. So for Salesforce.com 150 milliseconds is the absolute floor for any call – any call will take 150 milliseconds plus transmission time, marshalling and un-marshalling time, and actual processing time for the logic of the request.