function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
SuperfellSuperfell 

gzip matters

If you do nothing else, make sure your perf sensitive integrations are taking advantage of the sforce support for gzip. It could get you an easy 6x perf increase!.

see http://blog.sforce.com/sforce/2005/12/gzip_matters.html and
http://www.pocketsoap.com/weblog/2005/12/1583.html
qmanqman
Great work, thanks Simon!

One question, did the computer where you ran these tests have a hyperthread, dual core or multiple processors ? Integrations running on servers would be much more likely to have run with multiple processors and can truly support parallel threads.

It seems to me that multiple processors would change the read ahead impact, especially if you had long individual row processing times (say objects with large numbers of custom fields (>100).

Bill

Message Edited by qman on 12-05-2005 07:01 AM
SuperfellSuperfell
No, its running on a single core P4 box. obviously the longer the client's per row processing, and the larger the batch size, the more useful the read-ahead queryMore is. As typically both the per row processing and the queryMore call are blocked on IO, i'm not convinved that multiple processors/cores would make a big difference.