ESocketError under heavy load

rbuser

After improving the error handling in my report server to catch all
exceptions and re-raise EReportBuilderError's, I've done some more stress
testing.

When the report server is under heavy load (3 web clients continually
running reports), the report server eventually raises this error:
ESocketError 'Connection timed out.'
This results in a "TrsServer - Fatal Exception" message and the server dies.

I haven't been able to duplicate this with thin clients, only web clients.

I don't mind if the server raises errors under heavy load, but it shouldn't
die on me!

I could send you some code that should hopefully demonstrate the problem if
you'd like.

--
Nathan Sutcliffe
nsutcliffe at speedlinesolutions period com

nardmoseley

Have not heard of this before.

Can you duplicate this against our live report server?

http://www.digital-metaphors.com/rbServerLive



--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

> Have not heard of this before.

I don't think I can duplicate the same problem. I get "Unable to connect to
server" and occasionally, "Server is currently busy" but it always comes
back online. It takes several clients to kill my server but only one to get
these errors from your server.

--
Nathan Sutcliffe
nsutcliffe at speedlinesolutions period com

nardmoseley

Please specify steps I should take to recreate this error on our test
server.

--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

> Please specify steps I should take to recreate this error on our test

The easiest thing would be to send you the stress-tester application I
built - is there a way I can do that? I assume that posting or attaching 8K
of code to the newsgroup would be frowned upon...

--
Nathan Sutcliffe
nsutcliffe at speedlinesolutions period com

nardmoseley

Please send in zip format to support@digital-metaphors.com.



--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nard:

Please continue the discussion in this thread.

Thanks
Ed Dressel
Team DM

nardmoseley

Thanks for sending the tester app - finally had to time to look at it and
run it today.

First point I want to make is that the tester app is not simulating what
happens when real users access the server. The WebTier and Report Server are
both structured to manage user sessions. When a user views a report and then
decides to view another report, the first report is free'd up on the server.
This is all done within the context of a WebSession on the WebTier side and
a Server Session on the report server. Their is efficient management of
resources. The tester app creates many new sessions very quickly.

In my testing here I never receive any socket errors. I notice that running
the applications results one or both of the following.

a. The Server reaches the maximum number of sessions that it is configured
to support. This results in a web "server busy" page being displayed by the
WebTier that states that the server is busy with the maximum number of
sessions.

b. A DBISAM exception is thrown (presumably by the DBISAM dataset). This
results in an web "error" page being displayed that contains the error
message.

Neither of the above results in the the web tier or server crashing. The
server is simply overloaded and manages this.




--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

> First point I want to make is that the tester app is not simulating what
are
then
server.
and

That's good to know. My original stress tester did reuse session ids, but
that relied on certain custom features of my webtier. If you tried the
report server I sent, I think you could reproduce the ESocketError I'm
worried about. So far, I've only seen this issue with my stress tester, but
If I see it in our production server, I'll try to put together a better demo
to send you. It's hard to do when there are so many different pieces of
software involved.

--
Nathan Sutcliffe
nsutcliffe at speedlinesolutions period com

nardmoseley

I performed more tests, using the report server app that you sent. This app
contains a ReportVolume.BeforePublishReport event that loops and sleeps 1000
times to create a delay.

var
Index: Integer;
begin
// Tight loop to simulate a query:
for Index := 0 to 1000 do
Sleep( 1 );

This is not a real world example. However, I ran the test and was unable to
encounter any ESocketErrors.

You might try increasing the Server.TimeOut and
WebTier.SessionOptions.SessionTimeOut property values. These values
influence how long either app will wait before disconnecting. If the either
the webtier or server disconnects from the socket then the other party might
think that a socket error occurred.

We have had 0 reports of ESocketError from other customers.




--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com