watching threads and acting on it (redux)

[ccordes]

I thought I had the answer when i found this answer to pausing new activity if the server is too busy...
=======From Bruce ============
a) create a global mem variable, a LONG, unthreaded, called say ThreadsCount

b) In WebHandler, before the line;
p_web.ProcessRequest(p_ReqString)

add
p_web._wait()
ThreadsCount += 1
p_web._release()

and after the call to
p_web.ProcessRequest(p_ReqString)

put
p_web._wait()
ThreadsCount -= 1
p_web._release()

c) In WebServer procedure, StartNewThread method, after loc:RequestData :=: p_RequestData

If ThreadsCount >= x
  self.MakeErrorPage(500,'Server Busy','Server Busy, try again shortly')
  Return
End

The value you use for x will depend on the memory usage of each thread. And the only real way to know how high it can go is to monitor the value under load, and see at what point the server dies.
As a debugging tool you could write out the value to DebugView, or perhaps write it away to an Ini file or something here.

Cheers
Bruce
=================================
The thread count part seems to work alright, but responding to it from the StartNewThread method doesn't seem to work.
Mostly, I think, because MakeErrorPage returns a string (the error page) and StartNewThread doesn't. So what happens to the error page?
In my test, it just hangs the server.

Is there a more correct place to put this? Shouldn't it be in the WebHandler somewhere?

Thanks
Chris

[Bruce]

Hi Chris,

As it happens I was doing something similar yesterday, and got the same problem.
So, to keep it clean, I've added a "SendError" method to the web server - this will be in the 5.34 build.

If you're in a hurry, let me know.

cheers
Bruce

[ccordes]

Yeah, I could really use it.
Thanks
Chris

[Bruce]

Files sent to you via email.
Use

self.SendError(500,'Server Busy','Server Busy, try again shortly')

instead of

self.MakeErrorPage(500,'Server Busy','Server Busy, try again shortly')

Cheers
Bruce

[ccordes]

Thanks, Bruce! I'll be careful.

I couldn't get enough traffic by myself to test so I did some logging using debugview and _trace
I surrounded the ProcessRequest with Threadcnt +/- =1 and a self._Trace('Threads='&threadcnt)
set debugview log to a file and let it sit all day.

I would've thought that I'd get a log entry _every_ time a thread was started and another when it closed and that I'd see the count go up and down.
And, for the most part, that's about what I have. But there are places that it seems to jump numbers. from 3 to 12 in one instance. I thought that maybe I was starting threads elsewhere, but that wouldn't increment the threads counter.
Is this just a limitation of the debugviewer?
I probably have a bunch of other _trace calls everywhere too that I was filtering out

Aside from adding a timer in there, are there any other suggestions on determining when the server is getting into trouble?

chris

[Bruce]

Hi Chris,

One of the areas I've been working on for NetTalk 6 is performance management - that comes out in a couple weeks so perhaps you want to wait for that and build on what that offers?

cheers
Bruce

[ccordes]

NOW, you've got my attention. 

Doing the logging and watching the threads, the issue I see is that threads are not ending. Yesterday I had 27 sessions and 250 threads.
Now I'm working at a way to find out which ones. Any suggestions?
maybe a couple of traces inside ProcessRequest

chris

[Bruce]

Hi Chris,

Sounds like plenty of p_web._trace calls in your future <g>.
I guess the starting point is in figuring out which threads are getting "stuck". My guess is that it's some hand-code you've added somewhere <g>.

cheers
Bruce

[ccordes]

Yeah I am cleaning it up now to drop in new traces.
My first thought is that we are going outside to address verification. SOMEtimes that server hangs and my validateaddress function may not come back.
Also we produce labels from the USPS, FEdEx and UPS. That is where I'm focusing the tracing.

Any suggestions on handling a timeout in those cases? I currently use a timer event on a hidden window... maybe it isn't working.

[Bruce]

>> Any suggestions on handling a timeout in those cases? I currently use a timer event on a hidden window... maybe it isn't working.

there's a property for the NetSimple class .InactiveTimeout that is probably set by default to 60 seconds.

I'm assuming you have code in .ErrorTrap to properly take care of errors and close the client window? your most common errors are likely to be "failed to opens" and "timeouts".

cheers
Bruce