[ http://issues.apache.org/jira/browse/AXISCPP-749?page=comments#action_12355588 ]
John Hawkins commented on AXISCPP-749: -------------------------------------- Maybe I'm getting confused here. This algorithm essentially switches buffering yes? In which case I think what Fred is saying is if we knew there were lots of large messages going through we could set the algorithm on so that large messages got buffered and thus were more efficient? I think this is a sound idea, if not somewhat hard to implement (what's a "large" message? How long does it take to work out the message is "large" and then do the socket option compared to actually sending the data as is with no buffering? > Currently TCP_NODELAY is turned off. This is only efficient when the > messages are small. > ----------------------------------------------------------------------------------------- > > Key: AXISCPP-749 > URL: http://issues.apache.org/jira/browse/AXISCPP-749 > Project: Axis-C++ > Type: Improvement > Components: Transport (axis3), Transport (Client) > Versions: current (nightly) > Environment: n/a > Reporter: Fred Preston > Priority: Trivial > > When setting up the socket, the following initialisation is performed (see > the last few lines of method HTTPChannel::OpenChannel() and > HTTPSSLChannel::OpenChannel())... > /* Turn off the Nagle algorithm - Patch by Steve Hardy */ > /* This is needed, because our TCP stack would otherwise wait at most > * 200 ms before actually sending data to the server (while waiting for > * a full packet). This limits performance to around 5 requests per > * second, which is not acceptable. Turning off the Nagle algorithm > * allows for much faster transmission of small packets, but may > * degrade high-bandwidth transmissions. > */ > int one = 1; > setsockopt( m_Sock, IPPROTO_TCP, TCP_NODELAY, (char *) &one, sizeof( > int)); > When the message is not so small, does this omission degrade the socket > performance? Would it be better to set a threshold and perhaps change the > socket options 'on the fly' when the message size dictates that it should be > handled differently? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
