Tuning WinSock Outbound Data Transfer Performance
(Last modified: 22Nov2004)
This document (10095570) is provided subject to the disclaimer at the end of this document.
goal
Tuning WinSock Outbound Data Transfer Performance
fact
Novell NetWare 6.5 SP3
Novell NetWare 5.1 SP8
This document contains forward-looking statements regarding features of NetWare Support Packs that, at the time of writing, are not fully released. These feature plans are tentative and contingent upon successful testing. This document should not be considered a guarantee of delivery of these features in any product or support pack.
fix
Starting with NetWare versions 6.5 SP3 and 5.1 SP8, administrators will be able to tune the performance of programs using WinSock for outgoing data. If an application is using WinSock to send data and the application is passing data to WinSock faster than it can be processed by TCPIP or IPX/SPX, then WinSock returns an error message telling the application it needs to block and allow WinSock time to process the information before passing more data. This mechanism allows WinSock to prevent an application from consuming all of a systems memory resources if there is slow response or some other problem with a socket which prevents it from processing data.
There are three basic modes of I/O for WinSock; blocking, non-blocking and overlapped. (There are technically a couple more, but for the purposes of these parameters they are not significant). WinSock uses the following functions for sending data:
send()
sendto()
WSASend()
WSASendTo()
In blocking mode, a call to each of the sending functions requires that the data which is to be sent be completely processed before the call returns. WinSock on NetWare however cheats and copies the users buffer into its own and then handles the data itself, allowing the application to continue work without the need to wait for network latency and other factors.
Non-blocking mode sockets will return immediately and the application can use the select function to be notified when the send completes. However, the users data is also copied to WinSock's internal buffers in non-blocking mode.
Previously the internal buffer limit for outstanding send data was 65535 bytes of data before an error would be returned. With the new versions of NetWare, the default buffer size is 2,048,000 and it will be configurable to be as small as 65535 and as large as 100 megabytes. By increasing the maximum buffer size, performance can be improved. If the buffer size is too small, the application may spend much of its time blocking and not doing any work. Also, a small buffer size will leave TCPIP idle as well. The reason for this is that after the application blocks and before it is rescheduled, TCPIP may be finished sending the outstanding data. So there becomes a period when no work is done. By increasing the buffer size, TCPIP remains busy until the application is rescheduled. By that time, there will be more space available for data and the application can keep the buffer full.
For overlapped send calls with callbacks, WinSock does not copy the users buffers. The application is required to keep the send buffer available until the corresponding send callback function has been called. Because the buffers used for overlapped send belong to the application, WinSock controls the amount of outstanding data by limiting the number of send calls without a callback. Each call to a send is called a message. In previous versions of NetWare, the maximum number of outstanding messages was set to 128. In the new version, the default is 8192 outstanding messages before an error is returned. The administrator can set the value from 128 to 97567.
TransmitFile is a WinSock API which is intended to be used to quickly transfer files over the wire. It uses overlapped mode internally and its performance can be enhanced by tuning the maximum outstanding send messages.
CPU speed, memory size, LAN speed and the type of applications run on a server will determine the optimal size of the send buffers or send message parameters. All sockets created after a configuration change has been made will get the new sizes while sockets already allocated will keep the previous setting.
The buffer sizes are maximum values only. The sockets do not allocate the buffers, instead they are allocated from a pool as they are needed by the socket , up to the maximum value allowed and then returned to the pool, or freed if memory limits are exceeded.
There are two parameters which affect the maximum send buffer size and the maximum number of send messages. The syntax is as follows:
WS2_32 MAX_PENDING_SEND_BUFFER_SIZE #
WS2_32 MAX_SEND_MESSAGES #
MAX_PENDING_SEND_BUFFER_SIZE sets the maximum outstanding buffer size allowed for blocking and non-blocking sockets while MAX_SEND_MESSAGES sets the maximum number of outstanding send calls for overlapped sends with callbacks.
The # represents the number to be used. For example if the maximum number of buffers is to be set to 4 megabytes the set parameter will look as follows:
WS2_32 MAX_PENDING_SEND_BUFFER_SIZE 4000000.
If the # is not given for either command, the current values are displayed.
.document
| Document Title: | Tuning WinSock Outbound Data Transfer Performance |
| Document ID: | 10095570 |
| Solution ID: | NOVL99903 |
| Creation Date: | 22Nov2004 |
| Modified Date: | 22Nov2004 |
| Novell Product Class: | COMM/NFS |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.