Server Tuning Question ?

rbuser

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

rbuser

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.

nardmoseley

> 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.


PublishingMode
-------------------

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
www.digital-metaphors.com

rbuser

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

nardmoseley

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
www.digital-metaphors.com