Separate SSRS server, pros / cons?

  • Right now, I've got my SSRS instances sitting on the same servers as the databases they service.  There's some things that might be related to this (first time in the AM someone tries to access a report, it times out, but works fine from there,) and I'm thinking about splitting the SSRS and SQL back up (they were on separate servers in the past, when we had a Sharepoint system in-house.)

    I can think of a few cons to having them separate (more servers to patch and update,) and I can speculate on some of the pros (potentially better SSRS performance, one less thing sharing resources with SQL,) but I'm not sure the pros are going to be worth it.

    The current systems:

    • QA server, one SQL Server instance, 5x SSRS instances (one of those I'm thinking of removing)
    • 1x Production server, one SQL instance, 2x SSRS instances
    • 1x Production server, one SQL and 2x SSRS instances
    The production servers never seem starved for RAM or processor, the QA is a bit tighter, but it's QA.

    So, give me reasons to add more servers to keep happy, or reasons not to, please.

  • Pro's of seperating ssrs from database server:
    More resources available for the database
    More control of resources used. Resource management in SSRS is limited
    Possible to reboot SSRS without impacting database
    Cons:
    Requires extra licenses (see licensing guide microsoft, each server must be licensed)
    Slightly more networktraffic

  • jasona.work wrote:

    Right now, I've got my SSRS instances sitting on the same servers as the databases they service.  There's some things that might be related to this (first time in the AM someone tries to access a report, it times out, but works fine from there,) and I'm thinking about splitting the SSRS and SQL back up (they were on separate servers in the past, when we had a Sharepoint system in-house.)

    Morning slowdowns can be addressed setting RecycleTime = 0

    See the article:

    https://www.mssqltips.com/sqlservertip/2735/prevent-sql-server-reporting-services-slow-startup/

     

    To make a decision to separate SSRS from SQL, the lack of resources should be obvious (CPU, RAM).

    So, only monitoring of resource consumption  will help you to make a decision.

     

     

  • Andrey wrote:

    jasona.work wrote:

    Right now, I've got my SSRS instances sitting on the same servers as the databases they service.  There's some things that might be related to this (first time in the AM someone tries to access a report, it times out, but works fine from there,) and I'm thinking about splitting the SSRS and SQL back up (they were on separate servers in the past, when we had a Sharepoint system in-house.)

    Morning slowdowns can be addressed setting RecycleTime = 0 See the article: https://www.mssqltips.com/sqlservertip/2735/prevent-sql-server-reporting-services-slow-startup/   To make a decision to separate SSRS from SQL, the lack of resources should be obvious (CPU, RAM). So, only monitoring of resource consumption  will help you to make a decision.  

    Andrey thanks for the link and suggestion.  When I first looked at the article I thought I'd seen it before, but I checked the setting on my server and it was set to 720, so I've given it a try and changed the setting.

    We'll see what happens.

  • Jasona, you're welcome.

    Also, perhaps you find it useful - SSRS report which shows activity of a SSRS server (usage of reports).

    https://github.com/ASamykin/PerformanceReports/blob/master/Report%20Project1/SSRS_overview.rdl

    SSRS_Overview

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply