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;
| [reply] |
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] |
