Hi All, 

How can I tell if my listener threads are over worked , is there a gauge to monitor the performance of the listener threads?

Basically, We have many applications that constantly logon and logoff, when it gets really busy complaints are coming in that it takes too long for the application to load.

My hunch is that the listener thread is overworked therefore it does not yield so fast to new connections.

Is there any way to monitor it?

Thank you

Hi Joel,

The listener threads' business typically is small and doesn't extend far beyond tcp level accepting of a connection attempt (assuming we're talking tcp connections here), so those threads literally being overwhelmed isn't very likely.

But there's more that needs to happen for an SQL session to be opened (and even closed), some of which happens outside of the listener (but with the listener possibly having to wait on) and some happens after the listener's activity is complete (so again outside of the listener).  What's coming to mind are

• name resolution (including client IP address reverse resolution)
• authentication
• establishing (and later cleaning up of) the actual session, including maintaining the active session list (can become a bottleneck with very high frequency of sessions opening and closing).

What I'm trying to say: don't be too focused on listener threads.  A series of good old "onstat -g ath" outputs, at a time where you feel connections are slow, so a view on all threads, might provide first clues.  A series of "onstat -g stk all" outputs, obtained simultaneously with the afore mentioned, might provide further insights, esp. on those threads standing out in the thread overview.

HTH,
 Andreas

------------------------------
Andreas Legner
Informix Dev
HCL Software
------------------------------