Webtier scaleability problems

rbuser

Hi,

We are developing a web based reporting solution using SQL Server. We
are having problems with scaleability.

The two problems we are constantly having are

1- Access violation at address 01792208 in module REDReportCOMServer.ocx
Read of address 00000000

2- Error Type:
(0x8000FFFF)
Catastrophic failure
/report.asp, line 5


Browser Type:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)

Page:
POST 353 bytes to /report.asp

POST Data:
volume=Report+Explorer+Database&name=OpSys+++++++++++++++++++++++++%
5Crapporten+++++++++++++++++++++%5Crapportage++++++++++++++++++++%5C21-
22+doverz.+oplpt.+adv.&folder=v0d0d10d3&explorer=dynamic&Sess . . .


Where report.asp contains the following lines
---
<% @Language=JavaScript %>

<%
WebTier = Server.CreateObject("REDReportCOMServer.Reports");
Response.Write(WebTier.ProcessWebRequest(Request.QueryString,
Request.Form));
%>
---

If we start the reportserver standalone or as a service using the
ReportBuilder service and open reports one by one there is no problem.
However when we start to stress the server it almost immediately
collapses.

Notes
-----
Both the server and the ocx read settings values from the registry. The
datamodule in the reportserver reads these settings in the OnCreate
event of the datamodule so that when a new thread is started and a new
datamodule is created these settings are correct.
The datamodule uses 2 connections to different databases and each
connection has a single query attached to it. The OnCreate event also
dynamically builds the query strings and connection paramaters.


Any ideas??

regards
Paul Sjoerdsma

nardmoseley

In our tests here we do not have this problem.

Try to isolate the problem. Test the report server application by
accessing it with a ClientReport application (then add additional
ClientReport applications). This test does not involve the web tier
application at all. Thus it is simpler.

If the test above fails, then the problem is in the report server
application. My first guess is that the problem is one of thread-safety.
The code and components in your datamodule must be thread-safe. Each
datamodule requires a separate database connection object, such as an
ADOConnection.

You can try running the report server application under the Delphi
debugger. Set break on exceptions to true so that you can determine
where the failure occurs.

If you still have problems with the above, try to create a very simple
report server application that has only a few archive files. Test it for
scaleability. Then create a another simple report server that has only a
few simple .rtm report files. Make the reports very simple. Incrmentally
add complexity until you find the breaking point.

rbuser

Hi,

We tried to make the code in the datamodule thread-safe. A simple stress
test using about 10 clientexplorers worked reasobaly well. The only
exception that we got once in a while is a Stream read error.


AQTime
--------
Event Time

Exception $0EEDFADE Delphi exception at $77E8F142 (class: EReadError,
message: "Stream read error") 16:37:55:015
$77E8F142 KERNEL32.DLL RaiseException
$00425523 TStream::ReadBuffer in Classes line 4841
$00425523 TStream::ReadBuffer in Classes line 4841
$00513206 TrsTcpSocketStream::SendDataStream in rsTcpSocketStream
line 0
$00512CE4 TrsTcpSocketSoapStream::SendXMLMessage in rsTcpSocketStream
line 0
$00513436 TrsSoapTcpSocket::SendXMLMessage in rsSoapTcpSocket line 0

$005124A4 TrsServerAgent::SendXMLResponse in rsServerAgent line 0
$005126D2 TrsServerAgent::iServerResponse in rsServerAgent line 0
$004EB85F TrsServiceDelegate::SendResponse in rsServiceProvider line
0
$005989F7 TppPublisher::ReceivePage in ppDevice line 0
$005389B9 TppEngine::GeneratePage in ppEngine line 0
$00598AF6 TppPublisher::DoOnPageRequest in ppDevice line 0
$0059BB76 TppProducer::PublishReport in ppProd line 0
$0053592D TppReport::PrintToDevices in ppReport line 0
$005A1F0D TrsReportServiceAdapter::ProcessPageRequest in
rsReportServiceAdapter line 0
$005A38AE TrsReportPublishing:GeneratePages in
rsReportPublishingManagerLive line 0
$005A6AC5 TrsPublishReportDelegate::ProcessClientRequest in
rsReportServiceProvider line 0
$004EB5D2 TrsServiceDelegate::Execute in rsServiceProvider line 0
$004EB406 TrsServiceProvider::ProcessClientRequest in
rsServiceProvider line 0
$004EBFE6 TrsSession::ProcessRequest in rsSession line 0
$005121C0 TrsServerAgent::ProcessSoapRequest in rsServerAgent line 0

$005120D3 TrsServerAgent::Execute in rsServerAgent line 0
$005136C1 TrsTcpWorkerThread::PerformWork in rsTcpWorkerThread line 0

$005135A7 TrsTcpWorkerThread::Execute in rsTcpWorkerThread line 0
$0042DD7C ThreadProc in Classes line 9001
$00404985 ThreadWrapper in System line 11195
$77E87585 KERNEL32.DLL SetFilePointer



In article <3D91C49A.12279E13@digital-metaphors.com>, nard@digital-
metaphors.com says...

rbuser

Some additional info,

We have 2 connection components
1- To get the data for the folder and item pipeline
2- To associate with the report (FSharedConnection)
The connections point to different databases.

In the Module.OnCreate we read setting data from the registry.
We also added a TppDesigner. We use the
TrsReportExplorerVolume.OnLoadReportEnd to do the following

Designer.Report := TppReport(Sender);
Designer.DataSettings.SessionType := 'ADOSession';
Designer.DataSettings.DatabaseType := dtMSSQLServer;
Designer.DataSettings.DataBaseName := 'FSharedConnection';


I would think this is thread-safe but maybe not. I am also unsure where
the Stream Read Errors are coming from.

regards
Paul Sjoerdsma

In article <3D91C49A.12279E13@digital-metaphors.com>, nard@digital-
metaphors.com says...

rbuser

"Paul Sjoerdsma" wrote in message

nardmoseley

Remove the TppDesigner component form the datamodule. It is not
thread-safe and should never be included in a server application.

The SessionType, DatabaseType, DatabaseName values are stored with the
report definition at the time you create the report.

rbuser

Hi,

We removed the TppDesigner and instead of reading from the registry we
set all the necessary settings in the properties. To test the server We
used CLient explorers, around 15 and tested the server. On a regular
basis we get Connection timeouts and still get the Stream read errors.
The only difference between our server and the example server is that we
use TADOQueries instead of TADOTables. Could the connection timeouts
have anything to do with the Stream read errors??

regards
Paul

In article <3D91F70A.22B51DF4@digital-metaphors.com>, nard@digital-
metaphors.com says...

nardmoseley

The TADOConnection component has a CommandTimeOut property that defaults
to 30, that could be your problem. The ClientReport.ServerConnection has
a time out of 60.

When you say you are getting stream read errors, is this a message that
is returned to the Client? Or are you running the server from Delphi and
it is breaking on an exception?

Is SQLServer running on a stand alone server machine that has
performance to support the 15 simultaneous queries (assuming one query
per report)?

rbuser

First of all we changed to ISAPI (instead of COM+) and the problems
dissappeared.

Stream read errors where reported by running the server with AQTime.

SQL Server is a separate server, we have the development licence.

anyway, it seems to run ok now using ISAPI. We might go back and try the
COM+server another time.

regards
Paul

In article <3D932669.82199DA9@digital-metaphors.com>, nard@digital-
metaphors.com says...

nardmoseley

Thanks for the additional information.

We have not encountered any stream errors testing ASP here.