Re^6: How to count the number of pending clients in socket queue?

In this case (the OP). There is no argument.

I did some more investigation, and in doing so. Remembered I had tuned my kernel ( via sysctl) in such a way. That I receive more information, than is normally generated. Frankly, I haven't any idea whether it's even possible on Linux, and am quite sure, unavailable in Windows.
D'OH!

++ to you, kschwab. Apologies for the noise.

--Chris

#!/usr/bin/perl -Tw
use Perl::Always or die;
my $perl_version = (5.12.5);
print $perl_version;

Comment on Re^6: How to count the number of pending clients in socket queue?

Replies are listed 'Best First'.
Re^7: How to count the number of pending clients in socket queue? by kschwab (Vicar) on Nov 18, 2013 at 14:55 UTC
Actually, I think you're right. I checked out morgon's post below, and it looks like "Recv-Q" is overloaded for LISTEN sockets to show the current listenq depth. I experimented a bit and created a server that just listened, and never accept()ed. The number grows with each connected client, and stops growing at whatever you set the listenq size to. Connetions up to listenq size show as "ESTABLISHED", and ones after that show in a SYN-RECV state So, at least on linux then, you can use ss, netstat, or the /proc entry morgon pointed out...I was wrong. That said, I still think that spinning up more workers is best done by noting when you're out of them. That will happen before connections pile up on the listenq	[reply]

Replies are listed 'Best First'.

Re^7: How to count the number of pending clients in socket queue?
by kschwab (Vicar) on Nov 18, 2013 at 14:55 UTC

Actually, I think you're right. I checked out morgon's post below, and it looks like "Recv-Q" is overloaded for LISTEN sockets to show the current listenq depth. I experimented a bit and created a server that just listened, and never accept()ed. The number grows with each connected client, and stops growing at whatever you set the listenq size to. Connetions up to listenq size show as "ESTABLISHED", and ones after that show in a SYN-RECV state

So, at least on linux then, you can use ss, netstat, or the /proc entry morgon pointed out...I was wrong. That said, I still think that spinning up more workers is best done by noting when you're out of them. That will happen before connections pile up on the listenq

[reply]