Server Tuning Question ?

edited October 2009 in Server
I'm just starting to end-user test RB Server 10.06 and I'm seeing lot's
of database connections being made - several hundred from what appears
to be users running reports. Everything is working well but the
connections to the database aren't dropping when the reports finish as I
would expect them to.

What controls the disconnect from the database once a report is finished?

Jon Gray


  • edited October 2009
    This is more of a problem than I thought. We just maxed out the
    connections on the database because the sessions are not releasing.

    Any help controlling the connections to terminate would be appreciated.

  • edited October 2009
    > What controls the disconnect from the database once a report is finished?

    You can use the ReportVolume.PublishingOptions to control how the report is
    generated on the server. Check out the RBuilder help for the topics
    PublishingOptions and PublishingOptions.PublishingMode. I have pasted some
    relevant parts from the help below.

    For a given client, always use the same SessionID. If a SessionID requests a
    second report, then the first report module will be freed. If a SessionID
    does not make any requests for X amount of time then the session will time
    out on the server - thus the report module will be destroyed.

    You can use the Server.TimeOut property to specify the time out value in
    seconds. The default is 120.


    Specifies the manner in which reports are executed on the server.

    These are the valid PublishingMode values:

    pmFull -- Generates all pages for the report. Pages are cached
    on the server and sent to the client only when
    requested. This mode minimizes the amount of time
    that the report object and its associated database
    connection remain persistent on the server. However,
    uncessary processing may occur becauses the client
    may not request all pages.

    pmIncremental -- Incrementally generates pages as they are requested
    by the client. This mode minimizes processing on
    the server, but requires the report and its
    associated database connection to remain persistent
    on the server until the client either request all
    of the pages, the client request a different report,
    or the client session times out due to inactivity.

    Nard Moseley
    Digital Metaphors

    Best regards,

    Nard Moseley
    Digital Metaphors
  • edited October 2009
    Publishing Option pmFull does disconnect immediately for me.

    Where do I specify the SessionID to be the same so the previous module
    will be destroyed?

    Can you recommend some settings? I've got about 120 users that may all
    be running / viewing reports at the same time. Is it possible to limit
    the number of database connections say to 10 for 100 users?

    Delphi 2007 / RBServer 10.06 - Settings I have tried. Only pmFull
    disconnects from the database, pmIncremental never disconnects from the
    database until the rbserver is shutdown.

    reportvolume.PublishingOptions.PublishingMode := pmIncremental;

    rsWebTier1.ServerConnection.TimeOut := 120;

    rsWebTier1.SessionOptions.MaxReportCount := 125;
    rsWebTier1.SessionOptions.MaxSessionCount := 10;
    rsWebTier1.SessionOptions.SessionTimeout := 120;

    Should the session count be set to the approximate number of concurrent
    reports expected?

    Thanks - Jon Gray
  • edited October 2009
    The SessionID is automatically generated by the WebTier. You should not have
    to worry about it unless you are making custom calls to the webtier.

    The WebTier.SessionOptions.MaxSessionCount will limit the number of
    concurrent users that can view reports. (See the RBuilder help for details
    on WebTier.SessionOptions).

    If the report are short, then use the pmFull option and the report will
    generate and then free. With the pmIncremental option, pages are generated
    on demand, so the report instance and the connection are persistent. If you
    have common reports that many users will preview, then consider generating
    them to archives.

    The destruction of the report modules may not happen immediately when the
    session times out. A report module must be destroyed by the same thread that
    created it. (Howeer, there is not a dedicated thread for each report,
    because that type of implementation is too slow for a high performance
    server.) Once the same thread is activated it will check and destroy any
    report modules that are no longer in use.

    Nard Moseley
    Digital Metaphors

    Best regards,

    Nard Moseley
    Digital Metaphors
This discussion has been closed.