PQ93181: WEBSPHERE ZOS .3 SECOND DELAY SENDING SOME CHUNKED DATA BACK TO CLIENT. | |||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description In WebSphere zOS V5 some types of data sent as responses to the client my be sent CHUNKED. Is some instances there may be a delay during this transfer. We have measured it to be about .3 seconds. This delay is the result of normal TCPIP function, the sender of the data (WebSphere) may wait for the ACK or ACKnowledgement from the Client Stack before sending the next CHUNK. This APAR was opened to consider TCP changes that could be made on the WebSphere side to prevent the delay. NOTE: this delay is a wait, no additional CPU or other system resources are tied up in the delay. VERIFICATION STEPS: In this case the customer was running the WebSphere V5 PLUGIN in the zOS HTTP WebServer. We enabled the -vv trace in the WebServer and could see this .3sec delay after a HTTP write. This Write looks like 08:48:31.535725.: GWAPI: HTTPD_write()... successful The following trace message may differ in content but, will show the .3sec delay. For Example: 08:48:31.535725.: GWAPI: HTTPD_write()... successful 08:48:31.818681.: APIClassExec return_code=200; HTTP_RESPONSE=20 0; HTErrorInfo=0; ERRORINFO=0 Also, note that the Transfer-Encoding header looks like: Transfer-Encoding: chunked If the client is going directly to the WebSphere Transport, this delay still exists, just harder to identify. You may need to run TCPIP tracing.Local fix Set TCPIP NODELAYACK on the TCPIP STACK. Caution should be used if setting this value. This setting will improve performance when small amounts of data are being transferred. However, it could adversely affect transfer of large amounts of data.Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: Increase in response time on HTTP * * requests. * **************************************************************** * RECOMMENDATION: * **************************************************************** Delays in sending all the data for an http response can occur within TCP/IP when the response is sent out from the WebSphere Application Server in multiple pieces. Due to the Nagle algorithm TCP/IP may not send all the response data pieces immediately.Problem conclusion WebSphere Application Server will provide support to disable the algorithm by setting the TCP_NODELAY socket option on HTTP connections. The protocol_http_tcp_no_delay and protocol_https_tcp_no_delay server custom properties will be activated to allow the ability to control the configuration. A value of true is the default and will cause the Nagle algorithm to be disabled via the TCP_NODELAY option. For a value of false the server will not disable the Nagle algorithm. Changes will be made to the V5.0x and V5.1x WebSphere Application Server for z/OS Information Centers. To access the latest online documentation, go to the product library page at: www.ibm.com/software/webservers/appserv/zos_os390/library/ The following descriptions of the protocol_https_tcp_no_delay protocol_https_tcp_no_delay properties will be added to "Configuring server properties": protocol_http_tcp_no_delay Determines whether or not the setsockopt API is issued to set the TCP_NODELAY option for HTTP transport connections. A value of true indicates that the TCP_NODELAY option should be used for HTTP transport connections. This TCP/IP option disables the Nagle algorithm for all HTTP transport connections. Data Type Boolean Default True protocol_https_tcp_no_delay Determines whether or not the setsockopt API is issued to set the TCP_NODELAY option for HTTPS transport connections. A value of true indicates that the TCP_NODELAY option should be used for HTTPS transport connections. This TCP/IP option disables the Nagle algorithm for all HTTPS transport connections. Data Type Boolean Default True The table entries for the protocol_http_tcp_no_delay and protocol_https_tcp_no_delay properties included in the article "Changing the values of variables referenced in BBOM0001I messages" will be updated to indicate that the value specified for these properties can be changed in the administrative console by clicking Servers > Application Servers > server_name > Custom Properties > New and then adding the property and specifying a different value. These table entries will also include a link to the "Configuring server properties" article. These updated articles will be available in the next refresh of the V5.0x and V5.1x Information Centers. APAR PQ93181 is associated with SERVICE LEVEL W502016 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: PQ93374 Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PQ93181.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PQ93181
IBM Group: Software Group
Modified date: Nov 1, 2004
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.