Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As always with performance issues:</p> <ul> <li><strong>Don't prematurely optimize.</strong> If something's simpler in SSRS then do it there. Only when a problem arises consider trading clarity for performance (possibly by moving code to the SQL side).</li> <li><strong>Measure.</strong> Use the <a href="http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx" rel="nofollow">ExecutionLog2</a> view to get a general idea about where your bottle-necks are. Do more measuring and testing so you're sure you're investing time in improving performance of bits that matter.</li> </ul> <p><strong>Bottom line</strong>: let clarity of code guide where you solve a particular problem, and optimize selectively when performance becomes an issue.</p> <hr> <p>Eric Lippert wrote <a href="http://ericlippert.com/2012/12/17/performance-rant/" rel="nofollow">a nice blog post</a> about when and how to worry about performance. The context is C#, but the basic idea holds for other situations such as SSRS/SQL as well.</p> <p>By the way, if you have a look at mentioned <a href="http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx" rel="nofollow">ExecutionLog2</a> view, you'll notice that there's in fact <em>three</em> components in performance you should know about:</p> <ol> <li>Data retrieval (SQL)</li> <li>Report model (transforming the dataset to an internal model)</li> <li>Rendering (transforming the model into an XLS, PDF, etc)</li> </ol> <p>Knowing in which part a bottle-neck lies is key to knowing how to solve a performance problem.</p> <hr> <p>To end with a suggestion based on my experience:</p> <p>As a rule of thumb, <strong>prefer SQL over SSRS</strong> <em>if</em> you're worried about performance, especially for aggregation. Also consider tuning your database (indexes and such) if needed.</p> <p>This rule of thumb would be best if I could back it up by facts and research. Alas, I don't have any. I <em>can</em> say that in my own experience, most often when I had performance problems with reports moving aggregation and calculation from SSRS to SQL would help in solving this issue.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload