Slow MCP JSP Requests

[ed]

Has anyway noticed slow response times when POST'ing data to JSP backend requests. Slow response times seem to occur when the
data POST (ie. Content-Length) is small. Response times seem to be ok outside of the 700 to 1400 byte bracket.

Example showing a SLOW POST from MCP log:

2017-03-27 15:48:19.342 DBUG 0274018D-1000BD38-000E165C 3224 01F00000 FMUserRequest.cxx:547 Content-Length: 152
2017-03-27 15:48:19.342 DBUG 0274018D-1000BD38-000E165C 3224 01F00000 FMUserRequest.cxx:547 Content-Type: multipart/form-data; boundary=----------------------------51ce1f964bde
2017-03-27 15:48:19.582 DBUG 0274018D-1000BD38-000E165C 3224 01F00000 FMUserRequest.cxx:511 Request completed, sending RequestCompleteNotify.

In the request you can see it is taking 240ms to POST the REQUEST to the web server.

Another Example (220ms to POST the data):

2017-03-27 15:48:19.094 DBUG 0274018D-1000BD38-000E1653 3224 01F00000 FMUserRequest.cxx:547 Content-Length: 1053
2017-03-27 15:48:19.094 DBUG 0274018D-1000BD38-000E1653 3224 01F00000 FMUserRequest.cxx:547 Content-Type: multipart/form-data; boundary=----------------------------245a4b8174b2
2017-03-27 15:48:19.314 DBUG 0274018D-1000BD38-000E1653 3224 01F00000 FMUserRequest.cxx:511 Request completed, sending RequestCompleteNotify.

However when the Content-Length is larger, it is ok (20ms to POST the data).

2017-03-27 15:48:16.612 DBUG 0274018D-1000BD38-000E1637 3224 01F00000 FMUserRequest.cxx:547 Content-Length: 3862
2017-03-27 15:48:16.612 DBUG 0274018D-1000BD38-000E1637 3224 01F00000 FMUserRequest.cxx:547 Content-Type: multipart/form-data; boundary=----------------------------5b7bbc67bb0a
2017-03-27 15:48:16.632 DBUG 0274018D-1000BD38-000E1637 3224 01F00000 FMUserRequest.cxx:511 Request completed, sending RequestCompleteNotify.


is there any fix for this?

[ed]

The problem between MCP clients and web server, was a delay in MCP on sending the second packet until the first packet had been acknowledged by the web server.

SUN's implementation of TCP slowstart is active on the first packet by default, making the second packet wait for the first packet to be acknowledged — requiring a full round trip delay — plus up to 200 milliseconds of potential ack delay (RFC1122). The issue also occurred when the application was hosted on a Windows Server.

On a windows server, changing the following fixes the issue:

Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}*
* {Interface GUID} is different for every system.
TcpAckFrequency = 1

On a Solaris OS the following fixes the issue:

ndd -set /dev/tcp tcp_deferred_acks_max 1

Will need to check the consequence of changing this, as it is not recommended by Oracle to change the default value.

[cavagnaro]

Quite interesting, thanks for sharing