🚀 go-pugleaf

Patrick Wong wrote:

>The server creates a new thread to accept a client connection.  From the log
>file I can see processing is very smooth.  The rate of client requests does
>not differ from the begin of test to the time that error occurs.  If the
>server is overloaded, it should be not accepting at the very beginning, but
>not after an hour.  Is this a reasonable guess?

If the server can process the complete transaction before the next
request arrives, then all should be well.  If requests come in much
faster than the server can handle them, then it should fill up
quickly.  If requests are only slightly faster than completion, then
the que could slowly fill.

If you have access to the queue count (how many are waiting in the
queue) you might consider adding that value to your log.
Then you could see what's happening to the queue.
A slow, steady increase would mean a slow server (apply optimizing
techniques to the server).
A quick rise later on would be something getting trashed.

>> a time.  If the maximum number of clients are already queued, any further
>> clients will fail to connect until the queue opens up available slots.
>>
> At the time
>when problem occurred, requesting clients were blocked for more than five
>minutes.

That does seem odd to me.
I'm not at all familiar with what you're using, but  might there be a
boundry condition in the de-queing of a full queue that doesn't
correctly mark the last space as empty? Thus leaving the queue
thinking it is full?

>I hope I explained my problem clear enough.  I want to trace the reason of
>problem at the first place.  Are there any tools that can help?  I don't
>have equipment like network analyzer here.

For checking out slow file io (which might be a problem here too...),
I like filemon (file monitor) from www.sysinternals.com
Check out their other utilities as well.