Miscellaneous Ramblings on Hacking

June 8, 2010

RightNow .NET API Performance = Not So Good

Filed under: CRM, RightNow — Zack Bethem @ 1:59 am

Just a little update to my previous posting on RightNow‘s .NET API performance.

This API has me CRYING for their Apex Data Loader. Apex was FAST!!! It was extremely fast for selecting records. But it was even fast inserting and updating records. That was an awesome tool — dump the records out, massage them in Access using SQL, pump the records back in, go home an eat lunch. Done in 3hrs.

So here are the latest metrics:

RightNow .Net API

Extract: 1.5MM records in 1hr 4min

Update: 1.5MM records 3days+

Some of you may ask what is the update and how involved is it? I believe it to be a fairly simple task, myself. I’m updating each contact record and setting a custom field’s value to an externally assigned primary key. The one excuse I will allow RightNow is that there are 250 or so custom fields for the contact. I would expect some performance degradation, but a data conversion of 1.5mm records taking longer than 3days is just stupid.

I love coding in .Net, but man is this worthless!



  1. Hi, there are a number of items that you can do to increase the performance of your integration. I would encourage you to post any performance concerns on the RightNow Developer Community (http://communities.rightnow.com/developer) as we can help you diagnose issues.

    A few quick recommendations you should consider to improve your performance:
    1. Use batching, we have seen this improve integration performance by up to 10x
    2. Use multi-threading, Apex Data Loader is probably multithreaded. If you use multiple threads your integration will run much faster.
    3. Massage the data and omit the 250 custom fields you are not updating this will help with network latency.

    Again, I’d encourage you to post concerns on performance to our developer community so our engineers can help optimize the code for the best performance.


    Comment by rightnowdev — June 8, 2010 @ 4:37 pm

    • How about you post code and the performance you achieved in doing it? I still believe that Apex DataLoader is better. The RightNow architecture has some limitations — and this is a big one. Without it, you are just creating a data island.

      Yep.. this is my soapbox and I’m standing on it.

      Comment by Zack — June 8, 2010 @ 5:17 pm

      • I cannot post RightNow performance testing code out on the web, this is our code we use internally for functional and performance testing. We provide a number of public samples that highlight features like batching, updates, etc… And if you attend our Developer Conference in August (http://community.rightnow.com/customer/events/RDC.php) you can learn even more about working with the APIs.

        Apex DataLoader is a nice tool. However, unless you have written a multi-threaded application that leverages our batching capabilities you are really comparing apples to oranges. I think you will find if you write a multi-threaded application that utilizes batching you will see significant improvements in your performance.

        Again, we are happy to help look at your code and suggest ways to optimize it but this is done through our developer community. This way other developers working with RightNow Connect can benefit from that dialog.

        In addition, if you feel there are limitations in are architecture that are hindering performance, creating a data island or that simply make working with us too difficult we’d love to hear your suggestions for improvements on our Idea Lab (http://communities.rightnow.com/hives/7a939e0b53/summary)


        Comment by rightnowdev — June 8, 2010 @ 8:29 pm

      • unless you have written a multi-threaded application that leverages our batching capabilities you are really comparing apples to oranges

        That’s a valid point. Then again on the other hand, I don’t have to code anything when loading into Salesforce.com. It’s there. It’s done. It performs.

        Instead, you have “mystery” code that is said to perform that is only available for internal use. And, the code that is internal and does perform doesn’t have any proven benchmarks.

        So in the end, a client has to pay.. pay you or pay a developer to build something. Something that costs time and money. You’re not winning here.. the solution is still a sub-par solution in comparison.

        Comment by Zack — June 8, 2010 @ 10:10 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at WordPress.com.

%d bloggers like this: