all groups > sql server reporting services > march 2006 >
You're in the

sql server reporting services

group:

64-bit Reporting Services 2005 single-threading?


64-bit Reporting Services 2005 single-threading? SteveIrwin
3/26/2006 2:43:43 PM
sql server reporting services: We're running on an AMD 8-core Opteron, with Enterprise RS 2005 64-bit.
It seems that when we have multiple users running reports at the same time,
the mdx queries get executed in parallel to the AS database, but the
processing of the data by reporting services is done in a single-thread mode.
E.g. a report run by itself takes 15 seconds. Same report run by 5 people can
take 3:30 to return (with the w3wp taking up the equivalent of only 1 core).
My laptop running RS 2005 processes these simultaneous report faster than our
Opteron!!!

We played with setting the # of workers on the IIS Appl Pool, and it does
seem to cause multiple reports to be processed simultaneously, but I don't
think this is the best solution. I think we are running the equivalent of 8
copies of reporting services on the box in this configuration -- I see 8 RS
logs being generated.

Is there a setting in either IIS or RS 2005 to make it process requests in
parallel?

RE: 64-bit Reporting Services 2005 single-threading? TheTechie
3/28/2006 2:36:02 PM
Hi Steve,

Me too, interested to know the answer to your question. If you find out -
please update.

Thanks,
Al

[quoted text, click to view]
RE: 64-bit Reporting Services 2005 single-threading? SteveIrwin
3/29/2006 5:09:02 AM
It looks like the App Pool that gets created for RS has CPUAffinity assign to
it, I think. When you create another App Pool in IIS, and switch the
Reporting Services vdir to use the new pool, then it behaves like a regular
website -- one worker process that answers all requests that come to it,
spawning multiple threads if necessary.

So it comes down to how you want to have RS to work: do you want one worker
that spawns threads to handle requests, or have multiple workers that will
each take up only one cpu/core for each request, then move on to the next
request. It would be interested to see any whitepapers on this subject.

Steve

[quoted text, click to view]
AddThis Social Bookmark Button