4

I have coded a "GET" Apex web service which would return a list object and I want to load test my service. I already tried JMETER jp@gc plugin but I'm unable to get my result. Does anyone know how to load test OAuth service?

Thanks in Advance.

4
  • Welcome to the forum. I have used jMeter successfully to performance test Salesforce REST services. I haven't used jMeter with oAuth, but there are tutorials and plugins to support this. I think you have the correct approach, but it sounds like you need to configure your oAuth jMeter first.
    – Doug B
    Sep 4, 2013 at 11:08
  • Hi Doug, Thanks for your support. Since for oAuth i configured consumer secret and key but im unable to get the proper response. Do u share me how u configured jMeter for salesforce REST services? It will be very useful.
    – Dinesh
    Sep 4, 2013 at 11:17
  • I just used the regular jMeter download, plus the standard set of plugins from jmeter-plugins.org for some graphing. The basic body of the test was an HTTP Request, using a HTTP Header Manager and a User Defined Variables (where I kept session ID etc).
    – Doug B
    Sep 4, 2013 at 13:11
  • There is one more plugin called "jMeter OAuth Sampler" but it requires "Oauth token" and "token secret" ahead of Consumer key and secret.
    – Dinesh
    Sep 4, 2013 at 15:25

1 Answer 1

8

There is generally no need to perform load testing of the salesforce.com servers. Performance is routinely monitored, and performance issues are generally resolved proactively by salesforce.com before customers have a chance to notice that there is a problem. You can see a video on proper testing on youtube: Performance Monitoring and Testing the Salesforce Cloud.

Furthermore, load testing the salesforce.com service without explicit notification that you are doing so is may trigger an alarm that may prompt salesforce.com to shut down access to your organization. The system is tuned to handle normal loads, and a large influx of testing could cause performance degradation for multiple organizations that use the same database cluster.

Imagine 100 customers on the same database node deciding to send 100 transactions per second as a load test for an hour, and did so at the same time. Suddenly, the service would be hammered with 10,000 requests per second. Normal server load is about 500 to 1,000 requests per second, based on number of daily transactions and number of server clusters that are listed. This sort of coordinated testing would be paramount to subjecting the service to 10 or 20 times its normal load, possibly causing performance issues for all customers on that node.

Salesforce.com doesn't recommend stress testing their servers. They do that themselves, and they look at the larger picture than just any one organization (but, they do fine-tune individual orgs if they notice a problem). If you are still insisting on load testing, make sure you submit a case, get approval, and perform the test only during the scheduled testing time mutually agreed upon by yourself and salesforce.com.

In conclusion, it can be said that the reason you are using salesforce.com is so that you don't have to do this type of testing, monitoring, tuning, upgrading, etc. If you wanted to do that, you'd go buy a server and host your own Sugar CRM. Instead, just test your integration normally to make sure it performs at normal speeds. If you're concerned about performance, simply make sure you're following the tips for optimizing Apex Code, etc. Trust the system: it takes care of itself so you don't have to.

6
  • I understand what you're saying, but would you not agree with testing the system under the load you would expect in Production? It was only when we did this that we discovered an issue with record locking which led to a change in design.
    – Doug B
    Sep 4, 2013 at 12:02
  • "Testing under production load" is generally ill-advised, unless, of course, you have only a small number of licenses. If Merrill Lynch suggested this, salesforce.com would have performance issues on whatever server Merrill Lynch is on. By all means, do a "sample load", such as 10 requests/second for 30 seconds, if you're trying to test concurrency, but anything much larger than that should definitely be cleared with salesforce.com. After all, API rate limiting is in place for a reason; to prevent abuse.
    – sfdcfox
    Sep 4, 2013 at 12:23
  • Thanks for that. Just so I'm clear, is this because the Sandbox instances have production data volume but substantially less than production level processing power?
    – Doug B
    Sep 4, 2013 at 12:39
  • I believe overall sandbox processing power is comparable to production. There's fewer clusters, but some features are disabled, and there's higher API limits, etc, but generally less space (full-size Sandboxes are more expensive). It's not a matter of power, it's a matter of good stewardship. The power available isn't unlimited, so many people thrashing a server at the same time would of course have a negative impact.
    – sfdcfox
    Sep 4, 2013 at 14:22
  • Salesforce now also posted a blog about this: blogs.developerforce.com/engineering/2013/09/… Sep 23, 2013 at 13:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .