Kommt drauf an!
Einem Kollegen war aufgefallen, dass eine große Menge von Reports zeitlich sehr nahe beieinander erstellt wurden, obwohl die Laufzeit der einzelnen Reports dies nicht zulassen sollte.

Worauf kommt es nun an? Klare Antwort: Das liegt an der Konfiguration des Reportservers. Und hier liegt es genauer an der Option MaxQueueThreads. Laut Doku gilt folgendes:

MaxQueueThreads

Gibt die Anzahl der Threads an, die vom Berichtsserver-Windows-Dienst zur parallelen Verarbeitung von Abonnements und Benachrichtigungen verwendet werden. Gültige Werte sind 0 bis zu einer maximalen ganzen Zahl. Der Standardwert ist 0. Wenn Sie 0 auswählen, bestimmt der Berichtsserver die maximale Anzahl der Threads. Wenn Sie eine ganze Zahl eingeben, legt der angegebene Wert den oberen Grenzwert für das gleichzeitige Erstellen von Threads fest.

Auswirkungen

Leider wird dort nicht berichtet, wie der Berichtsserver entscheidet welchen Grad der Parallelität er aktuell wählen möchte. Man sieht aber auf jeden Fall bei datengesteuerten Abos einen deutlichen Anstieg der CPU, wenn viele Anfragen gleichzeitig verarbeitet werden.

Ein Punkt ist auf jeden Fall noch zu berücksichtigen: Die Datenbeschaffung muss auch parallelisierbar sein, das heißt z. B. wenn eine Prozedur aufgerufen wird, muss sie auch parallel ausführbar sein und keine permanenten Tabellen beschreiben. Alle Zwischenwerte sind in temporären Tabellen oder Tabellenvariablen zu halten.

Mehr Infos zur Parallelität auch innerhalb eines Reports verspricht dieser blog-Eintrag.