[vwnc] [Opentalk] What is listener backlog?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments.

Thank you.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Specifically, I'm just poking around to see if there's something in the
image that I can tweak to deal with an occasional RST frame coming back
from a port to which Opentalk binds (9001/tcp in the following example),

4341 > 9001 [SYN] (load balancer wants a connection with an opentalk
port)
9001 > 4341 [SYN, ACK] (that port agrees)
4341 > 9001 [ACK] (handshake completes)
9001 > 4341 [RST] (opentalk port sends first reset)
4341 > 9001 [PSH, ACK] (load balancer sends HTTP GET)
9001 > 4341 [RST] (opentalk port sends second reset)

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: Boris Popov
Sent: Tuesday, March 10, 2009 3:10 PM
To: VWNC,
Subject: [Opentalk] What is listener backlog?

ConnectionListener class>>listenerBacklog
 ^1
 
What exactly does this parameter control? Ultimately it gets down to,
 
 socket
   bindTo: (IPSocketAddress hostAddress: address port: self port);
   listenFor: self listenerBacklog.
 
but I'm not quite sure I understand what effect different value would
have.
 
Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

 

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thomas,

I guess in my case this doesn't apply, because I am getting as far as
receiving SYN, ACK from the server; although RST comes back after the
final ACK of a handshake, so I'm not convinced connection was
established fully?

4341 > 9001 [SYN] (load balancer wants a connection with an opentalk
port)
9001 > 4341 [SYN, ACK] (that port agrees)
4341 > 9001 [ACK] (handshake completes)
9001 > 4341 [RST] (opentalk port sends first reset)
4341 > 9001 [PSH, ACK] (load balancer sends HTTP GET)
9001 > 4341 [RST] (opentalk port sends second reset)

Interesting data point, WaveIPRequestBroker uses a default backlog of
128, but other brokers (including this Seaside one) just have 1.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, March 10, 2009 3:22 PM
To: Boris Popov; [hidden email]
Subject: RE: [Opentalk] What is listener backlog?

Boris,

 

Check the Unix man pages for the socket library functions.

 

Basically, the "backlog" is the number of pending connection requests
the O/S will buffer for you on the listener socket.  A "connection" on
the server side creates a new data socket to handle the actual transfer.
That is, a "connection" port is like a class, which when received
creates a "data" port as the instance of the connection.  Depending on
what you're doing, you normally don't need a backlog bigger than 1 or 2.
It's designed for cases where there could be some non-trivial,
measurable delay between getting the notification that you have a new
connection and actually creating the data port for that connection.

 

Cheers!

 

Tom Hawker



Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 

________________________________

From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 10, 2009 3:10 PM
To: VWNC,
Subject: [vwnc] [Opentalk] What is listener backlog?

 

ConnectionListener class>>listenerBacklog

 ^1

 

What exactly does this parameter control? Ultimately it gets down to,

 

 socket
   bindTo: (IPSocketAddress hostAddress: address port: self port);
   listenFor: self listenerBacklog.

 

but I'm not quite sure I understand what effect different value would
have.

 

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is
not intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses,
interception or interference and anyone who communicates with us by
email is taken to accept the risks in doing so.  Without limitation,
OOCL and its affiliates accept no liability whatsoever and howsoever
arising in connection with the use of this email.  Under no
circumstances shall this email constitute a binding agreement to carry
or for provision of carriage services by OOCL, which is subject to the
availability of carrier's equipment and vessels and the terms and
conditions of OOCL's standard bill of lading which is also available at
http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Here's an update for anyone who is listening (pun intended). The
following seems to have resolved this ongoing issue for us (fingers
crossed),

SeasideServer current configuration listenerBacklog: 128.

The default value for Opentalk brokers, such as Seaside in our case, is
normally 1, but it appears that for systems that experience any kind of
serious load, it's not nearly enough. This is also somewhat confirmed by
the fact that we had not seen this issue with our real-time API, which
is based on VisualWave and default listener backlog value there is 128.
There's also this Microsoft KB article,

http://support.microsoft.com/kb/113576

I've requested via support that the team review default choice of 1 for
these brokers, maybe consider using SOMAXCONN for Winsock2 as per: "A
value for the backlog of SOMAXCONN is a special constant that instructs
the underlying service provider responsible for socket s to set the
length of the queue of pending connections to a maximum reasonable
value."

http://msdn.microsoft.com/en-us/library/ms739168(VS.85).aspx

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 10, 2009 3:59 PM
To: [hidden email]; [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Thomas,

I guess in my case this doesn't apply, because I am getting as far as
receiving SYN, ACK from the server; although RST comes back after the
final ACK of a handshake, so I'm not convinced connection was
established fully?

4341 > 9001 [SYN] (load balancer wants a connection with an opentalk
port)
9001 > 4341 [SYN, ACK] (that port agrees)
4341 > 9001 [ACK] (handshake completes)
9001 > 4341 [RST] (opentalk port sends first reset)
4341 > 9001 [PSH, ACK] (load balancer sends HTTP GET)
9001 > 4341 [RST] (opentalk port sends second reset)

Interesting data point, WaveIPRequestBroker uses a default backlog of
128, but other brokers (including this Seaside one) just have 1.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, March 10, 2009 3:22 PM
To: Boris Popov; [hidden email]
Subject: RE: [Opentalk] What is listener backlog?

Boris,

 

Check the Unix man pages for the socket library functions.

 

Basically, the "backlog" is the number of pending connection requests
the O/S will buffer for you on the listener socket.  A "connection" on
the server side creates a new data socket to handle the actual transfer.
That is, a "connection" port is like a class, which when received
creates a "data" port as the instance of the connection.  Depending on
what you're doing, you normally don't need a backlog bigger than 1 or 2.
It's designed for cases where there could be some non-trivial,
measurable delay between getting the notification that you have a new
connection and actually creating the data port for that connection.

 

Cheers!

 

Tom Hawker



Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 

________________________________

From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 10, 2009 3:10 PM
To: VWNC,
Subject: [vwnc] [Opentalk] What is listener backlog?

 

ConnectionListener class>>listenerBacklog

 ^1

 

What exactly does this parameter control? Ultimately it gets down to,

 

 socket
   bindTo: (IPSocketAddress hostAddress: address port: self port);
   listenFor: self listenerBacklog.

 

but I'm not quite sure I understand what effect different value would
have.

 

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is
not intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses,
interception or interference and anyone who communicates with us by
email is taken to accept the risks in doing so.  Without limitation,
OOCL and its affiliates accept no liability whatsoever and howsoever
arising in connection with the use of this email.  Under no
circumstances shall this email constitute a binding agreement to carry
or for provision of carriage services by OOCL, which is subject to the
availability of carrier's equipment and vessels and the terms and
conditions of OOCL's standard bill of lading which is also available at
http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

FYI, listener backlog setting change from 1 to 128 has done wonders for
our system in the 2 weeks since its deployment. I would strongly
encourage the team to consider changing their choice of 1 as a default
value.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Thursday, March 12, 2009 12:40 PM
To: [hidden email]; [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Here's an update for anyone who is listening (pun intended). The
following seems to have resolved this ongoing issue for us (fingers
crossed),

SeasideServer current configuration listenerBacklog: 128.

The default value for Opentalk brokers, such as Seaside in our case, is
normally 1, but it appears that for systems that experience any kind of
serious load, it's not nearly enough. This is also somewhat confirmed by
the fact that we had not seen this issue with our real-time API, which
is based on VisualWave and default listener backlog value there is 128.
There's also this Microsoft KB article,

http://support.microsoft.com/kb/113576

I've requested via support that the team review default choice of 1 for
these brokers, maybe consider using SOMAXCONN for Winsock2 as per: "A
value for the backlog of SOMAXCONN is a special constant that instructs
the underlying service provider responsible for socket s to set the
length of the queue of pending connections to a maximum reasonable
value."

http://msdn.microsoft.com/en-us/library/ms739168(VS.85).aspx

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 10, 2009 3:59 PM
To: [hidden email]; [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Thomas,

I guess in my case this doesn't apply, because I am getting as far as
receiving SYN, ACK from the server; although RST comes back after the
final ACK of a handshake, so I'm not convinced connection was
established fully?

4341 > 9001 [SYN] (load balancer wants a connection with an opentalk
port)
9001 > 4341 [SYN, ACK] (that port agrees)
4341 > 9001 [ACK] (handshake completes)
9001 > 4341 [RST] (opentalk port sends first reset)
4341 > 9001 [PSH, ACK] (load balancer sends HTTP GET)
9001 > 4341 [RST] (opentalk port sends second reset)

Interesting data point, WaveIPRequestBroker uses a default backlog of
128, but other brokers (including this Seaside one) just have 1.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, March 10, 2009 3:22 PM
To: Boris Popov; [hidden email]
Subject: RE: [Opentalk] What is listener backlog?

Boris,

 

Check the Unix man pages for the socket library functions.

 

Basically, the "backlog" is the number of pending connection requests
the O/S will buffer for you on the listener socket.  A "connection" on
the server side creates a new data socket to handle the actual transfer.
That is, a "connection" port is like a class, which when received
creates a "data" port as the instance of the connection.  Depending on
what you're doing, you normally don't need a backlog bigger than 1 or 2.
It's designed for cases where there could be some non-trivial,
measurable delay between getting the notification that you have a new
connection and actually creating the data port for that connection.

 

Cheers!

 

Tom Hawker



Senior Framework Developer

Home

+1 (408) 274-4128

The Environment:

We take it personally

Office

+1 (408) 576-6591

Mobile

+1 (408) 835-3643

 

________________________________

From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 10, 2009 3:10 PM
To: VWNC,
Subject: [vwnc] [Opentalk] What is listener backlog?

 

ConnectionListener class>>listenerBacklog

 ^1

 

What exactly does this parameter control? Ultimately it gets down to,

 

 socket
   bindTo: (IPSocketAddress hostAddress: address port: self port);
   listenFor: self listenerBacklog.

 

but I'm not quite sure I understand what effect different value would
have.

 

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.

 

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is
not intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses,
interception or interference and anyone who communicates with us by
email is taken to accept the risks in doing so.  Without limitation,
OOCL and its affiliates accept no liability whatsoever and howsoever
arising in connection with the use of this email.  Under no
circumstances shall this email constitute a binding agreement to carry
or for provision of carriage services by OOCL, which is subject to the
availability of carrier's equipment and vessels and the terms and
conditions of OOCL's standard bill of lading which is also available at
http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov wrote:
> FYI, listener backlog setting change from 1 to 128 has done wonders for
> our system in the 2 weeks since its deployment. I would strongly
> encourage the team to consider changing their choice of 1 as a default
> value.


I didn't follow this thread, but using 1 is obviously broken.
Only single-threaded servers want a low number like 1...5.

Servers 'as we usually construct them' here are multithreaded and *need*
an OS-supported queue of pending connection attempts to remain performant.




I don't know what the current situation is, but ages ago you could
simply specify a huge number for the backlog to use (at least on
unixen), the OS would then reduce it to the maximum allowed value (which
is dependent on the runtime configuration of the OS).


So I advise to use 'SmallInteger maxVal' or something similar, 128 might
be a tad low for some installations.




HTH,

Reinout
-------
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout,

Given that today's system resources can't possibly be used as an excuse
for using 1 on any platform that VisualWorks supports, I can't see why
setting it to a max possible value is a bad thing (say, SOMAXCONN?).

"A value for the backlog of SOMAXCONN is a special constant that
instructs the underlying service provider responsible for socket s to
set the length of the queue of pending connections to a maximum
reasonable value."

"The backlog parameter is limited (silently) to a reasonable value as
determined by the underlying service provider. Illegal values are
replaced by the nearest legal value. There is no standard provision to
find out the actual backlog value."

http://msdn.microsoft.com/en-us/library/ms739168(VS.85).aspx

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Reinout Heeck
Sent: Tuesday, March 24, 2009 10:25 AM
To: [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Boris Popov wrote:
> FYI, listener backlog setting change from 1 to 128 has done wonders
for
> our system in the 2 weeks since its deployment. I would strongly
> encourage the team to consider changing their choice of 1 as a default
> value.


I didn't follow this thread, but using 1 is obviously broken.
Only single-threaded servers want a low number like 1...5.

Servers 'as we usually construct them' here are multithreaded and *need*

an OS-supported queue of pending connection attempts to remain
performant.




I don't know what the current situation is, but ages ago you could
simply specify a huge number for the backlog to use (at least on
unixen), the OS would then reduce it to the maximum allowed value (which

is dependent on the runtime configuration of the OS).


So I advise to use 'SmallInteger maxVal' or something similar, 128 might

be a tad low for some installations.




HTH,

Reinout
-------
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

In general, I agree that having the listener listen with a queue size of
1 is likely to cause issues. I have the issue marked to look at.

Cheers,
Michael

Boris Popov wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris,

First I'd like to thank you for the effort you spent figuring out the problem and letting us know how to solve it. I'm sorry about not chiming in earlier but I just didn't have the time to follow up and read the recommendations you found. I'd certainly be willing to reflect any official MS recommendation for Windows platforms, but I'm not ready to just max the parameter out wholesale. I have a somewhat vague memory about an article arguing in the exactly opposite direction, unfortunately I don't have any more specific reference atm. Either way, backlog is yet another tuning parameter, which people may need to work with in more demanding deployments. It may well be the one thing that can save a server from being swamped with connection requests. Letting the overflow be trimmed right down at the OS level may well be the thing that would allow the server deal with what it can.

Now I'm not saying that you shouldn't increase it, it clearly helped in your case, but I don't think that wholesale increase is a slam dunk either just yet. The backlog is an OS level queue. If VW lets a pending connection request sit in there for a while (e.g. because it's busy computing actual responses or some such) long enough that the client eventually times out and drops the connection anyway, I think the client would be much happier to get the immediate RST. I guess my main point is that there probably isn't a single optimal configuration that we can ship out of the box. I have to admit that at this point I'm inclined to ship it configured more tightly, so that you can't really overwhelm the server to the point where it bogs down and starts being really sluggish, something that we used to have a problem with back in the early VW7 time-frame. Ideally we'd do much better job explaining the default configuration and the various tuning parameters available and discuss exa!
 mples like yours.

Anyway, I'm not saying we won't make the change you recommend. We need to do more research and experiments to make the call. You've only looked at Windows so far, we certainly need to evaluate the Unix side of things as well. If others have experiences in this area, I'd certainly appreciate more feedback about this.

Finally, I thought you were in contact with support about this and that there is already an AR. If there isn't I'll make one shortly.

Cheers,

Martin

"Boris Popov"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov wrote:
For those of us using Linux (from the listen man page) the following
might be helpful:

       The  behavior of the backlog argument on TCP sockets changed with
Linux
       2.2.  Now it specifies the  queue  length  for  completely
established
       sockets  waiting  to  be  accepted, instead of the number of
incomplete
       connection requests.  The maximum length of the  queue  for
incomplete
       sockets  can be set using
/proc/sys/net/ipv4/tcp_max_syn_backlog.  When
       syncookies are enabled there is no logical maximum length and
this set-
       ting is ignored.  See tcp(7) for more information.

       If    the   backlog   argument   is   greater   than   the  
value   in
       /proc/sys/net/core/somaxconn, then it is  silently  truncated
to  that
       value;  the  default  value  in  this  file  is 128.  In kernels
before
       2.4.25, this limit was a hard coded value, SOMAXCONN,  with  the
value
       128.


David

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Martin,

I've asked support to create an AR, but I hadn't seen one yet. It might
be there, but without my contact details attached though.

I will let you review this with your team and come to appropriate
conclusions, but I just wanted to once again express how bad side
effects can be from immediate RST in a world of web applications. If you
have a webpage that includes multiple resources (pretty much every page,
some more than others) for which most browsers spawn parallel threads to
optimize download times, getting a single immediate RST results in
various degrees of broken-ness:

- missing CSS = nasty looking page
- missing JS = things not working
- missing images = things not appearing

We don't run a system under particularly heavy load and we saw a lot of
errors relating to this in the most basic of deployments. Given that WTK
has always used a value of 128, I just can't see why at least
Opentalk-Seaside needs a lengthy review process ;)

Let me know if there's anything else I can help with, I'm all for making
this platform a success.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 12:41 PM
To: Boris Popov
Cc: Reinout Heeck; [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Boris,

First I'd like to thank you for the effort you spent figuring out the
problem and letting us know how to solve it. I'm sorry about not chiming
in earlier but I just didn't have the time to follow up and read the
recommendations you found. I'd certainly be willing to reflect any
official MS recommendation for Windows platforms, but I'm not ready to
just max the parameter out wholesale. I have a somewhat vague memory
about an article arguing in the exactly opposite direction,
unfortunately I don't have any more specific reference atm. Either way,
backlog is yet another tuning parameter, which people may need to work
with in more demanding deployments. It may well be the one thing that
can save a server from being swamped with connection requests. Letting
the overflow be trimmed right down at the OS level may well be the thing
that would allow the server deal with what it can.

Now I'm not saying that you shouldn't increase it, it clearly helped in
your case, but I don't think that wholesale increase is a slam dunk
either just yet. The backlog is an OS level queue. If VW lets a pending
connection request sit in there for a while (e.g. because it's busy
computing actual responses or some such) long enough that the client
eventually times out and drops the connection anyway, I think the client
would be much happier to get the immediate RST. I guess my main point is
that there probably isn't a single optimal configuration that we can
ship out of the box. I have to admit that at this point I'm inclined to
ship it configured more tightly, so that you can't really overwhelm the
server to the point where it bogs down and starts being really sluggish,
something that we used to have a problem with back in the early VW7
time-frame. Ideally we'd do much better job explaining the default
configuration and the various tuning parameters available and discuss
examples like yours.

Anyway, I'm not saying we won't make the change you recommend. We need
to do more research and experiments to make the call. You've only looked
at Windows so far, we certainly need to evaluate the Unix side of things
as well. If others have experiences in this area, I'd certainly
appreciate more feedback about this.

Finally, I thought you were in contact with support about this and that
there is already an AR. If there isn't I'll make one shortly.

Cheers,

Martin

"Boris Popov"<[hidden email]> wrote:
> Reinout,
>
> Given that today's system resources can't possibly be used as an
> excuse for using 1 on any platform that VisualWorks supports, I can't
> see why setting it to a max possible value is a bad thing (say,
SOMAXCONN?).
>
> "A value for the backlog of SOMAXCONN is a special constant that
> instructs the underlying service provider responsible for socket s to
> set the length of the queue of pending connections to a maximum
> reasonable value."
>
> "The backlog parameter is limited (silently) to a reasonable value as
> determined by the underlying service provider. Illegal values are
> replaced by the nearest legal value. There is no standard provision to
header.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Also, as far as concerns that larger value results in increased risk of
things like SYN attacks, see the following article,

http://support.microsoft.com/default.aspx?scid=kb;en-us;142641 

Interesting fact, IIS uses default backlog of 25 and Apache 2.2 uses 511
(weird number, eh?),

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#listenbacklog

Even more information is available here,

http://tangentsoft.net/wskfaq/advanced.html#backlog

You can also Google for values that other applications use, I haven't
found any that use 1 yet ;)

Hope this helps,

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Boris Popov
Sent: Tuesday, March 24, 2009 12:50 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Martin,

I've asked support to create an AR, but I hadn't seen one yet. It might
be there, but without my contact details attached though.

I will let you review this with your team and come to appropriate
conclusions, but I just wanted to once again express how bad side
effects can be from immediate RST in a world of web applications. If you
have a webpage that includes multiple resources (pretty much every page,
some more than others) for which most browsers spawn parallel threads to
optimize download times, getting a single immediate RST results in
various degrees of broken-ness:

- missing CSS = nasty looking page
- missing JS = things not working
- missing images = things not appearing

We don't run a system under particularly heavy load and we saw a lot of
errors relating to this in the most basic of deployments. Given that WTK
has always used a value of 128, I just can't see why at least
Opentalk-Seaside needs a lengthy review process ;)

Let me know if there's anything else I can help with, I'm all for making
this platform a success.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, March 24, 2009 12:41 PM
To: Boris Popov
Cc: Reinout Heeck; [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

Boris,

First I'd like to thank you for the effort you spent figuring out the
problem and letting us know how to solve it. I'm sorry about not chiming
in earlier but I just didn't have the time to follow up and read the
recommendations you found. I'd certainly be willing to reflect any
official MS recommendation for Windows platforms, but I'm not ready to
just max the parameter out wholesale. I have a somewhat vague memory
about an article arguing in the exactly opposite direction,
unfortunately I don't have any more specific reference atm. Either way,
backlog is yet another tuning parameter, which people may need to work
with in more demanding deployments. It may well be the one thing that
can save a server from being swamped with connection requests. Letting
the overflow be trimmed right down at the OS level may well be the thing
that would allow the server deal with what it can.

Now I'm not saying that you shouldn't increase it, it clearly helped in
your case, but I don't think that wholesale increase is a slam dunk
either just yet. The backlog is an OS level queue. If VW lets a pending
connection request sit in there for a while (e.g. because it's busy
computing actual responses or some such) long enough that the client
eventually times out and drops the connection anyway, I think the client
would be much happier to get the immediate RST. I guess my main point is
that there probably isn't a single optimal configuration that we can
ship out of the box. I have to admit that at this point I'm inclined to
ship it configured more tightly, so that you can't really overwhelm the
server to the point where it bogs down and starts being really sluggish,
something that we used to have a problem with back in the early VW7
time-frame. Ideally we'd do much better job explaining the default
configuration and the various tuning parameters available and discuss
examples like yours.

Anyway, I'm not saying we won't make the change you recommend. We need
to do more research and experiments to make the call. You've only looked
at Windows so far, we certainly need to evaluate the Unix side of things
as well. If others have experiences in this area, I'd certainly
appreciate more feedback about this.

Finally, I thought you were in contact with support about this and that
there is already an AR. If there isn't I'll make one shortly.

Cheers,

Martin

"Boris Popov"<[hidden email]> wrote:
> Reinout,
>
> Given that today's system resources can't possibly be used as an
> excuse for using 1 on any platform that VisualWorks supports, I can't
> see why setting it to a max possible value is a bad thing (say,
SOMAXCONN?).
>
> "A value for the backlog of SOMAXCONN is a special constant that
> instructs the underlying service provider responsible for socket s to
> set the length of the queue of pending connections to a maximum
> reasonable value."
>
> "The backlog parameter is limited (silently) to a reasonable value as
> determined by the underlying service provider. Illegal values are
> replaced by the nearest legal value. There is no standard provision to
header.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

AR56702 is created and in review, so it'll be in 7.7.

Cheers,
Michael

Boris Popov wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

>From VisualWave.WaveIPRequestBroker class>>listenerBacklog

listenerBacklog
        ListenerBacklog isNil ifTrue: [ListenerBacklog := 128].
        ^ListenerBacklog.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Lucas-Smith
Sent: Tuesday, March 24, 2009 4:11 PM
To: Boris Popov
Cc: [hidden email]
Subject: Re: [vwnc] [Opentalk] What is listener backlog?

AR56702 is created and in review, so it'll be in 7.7.

Cheers,
Michael

Boris Popov wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc