Re: fet_buf_size

Keith, Here are 2 email messages I received from tech support on FET_BUF_SIZE. This feature is available for Unix client apps as well as PC client apps, but you need the correct version. I don't know there numbers off-hand. Hope this helps, Steve Berg - spb@masada.nb.com ---------------------------------------------------------------------------- Email message 1 ... Communications Buffer --------------------- The communications buffer is the location where data is held by the Informix communication software before being passed to the network communications software (like TCP/IP). The size of the communications buffer is set using the "b" option in the sqlhosts file. The "b" option controls the amount of data stored in the buffer before transferring across the network. On the server side (sqlhosts) this will determine how much data the server stores before sending to the client. On the client side (sqlhosts) this will determine how much data the client stores before sending to the server. The communication buffer is not a network packet and the "b" option does not control network packet size. The packet size is fixed based on the operating system and network software you are running. The default value for "b" is machine/network driver dependant. Following are some default network driver sizes for Hewlett Packard: HP-UX 9.0 using ethernet it is 4KB HP-UX 9.0 using FDDI it is 16KB HP-UX 10.0 using FDDI it is 32KB Informix recommendations: 1. Set the client-side communications buffer size and the server-side communications buffer size to the same value. In other words set "b" to the same value in the client sqlhosts file and the server sqlhosts file. 2. Changing "b" does not have much impact on performance, so let "b" default to the network driver size. Tune the fetch buffer size instead. 3. If changed, ensure that "b" >= network driver size. Talk to the network and operating system people before tuning "b" as there are many issues. Fetch Buffer ------------ The fetch buffer is a location in a client application's memory where cursor data received from the server is held before presentation to the application. It is the amount of data the client will accept from the server without waiting to send a "received" message. The FET_BUF_SIZE environment variable or the global FetBufSize ESQL/C variable is used to set the size of the application fetch buffer. Remember, however, that the underlying network will still send packets based on the network driver size regardless of what value FET_BUF_SIZE has. For example, if the FET_BUF_SIZE is set to 32K and the network driver size is 4K then 8 4K packets will be sent. This configuration would reduce network overhead if many rows are being returned, but could downgrade performance if only a small number of rows are returned (will return 32K of data, regardless). The default value for the fetch buffer size is determined as follows: 1. If a row being returned fits in a 4K (4096 bytes) buffer, the default size is 4K. 2. If a row being returned is greater than 4K, the default default size is the size of the row. If the user sets the FET_BUF_SIZE environment variable or the global FetBufSize ESQL/C variable, then the product uses the specified value or the default which ever value is largest. This means that the fetch buffer can never be smaller than 4K. Note- the algorithm for default fetch buffer size listed in 7.1UC1 version of the ESQL/C manual (pg 10-21) is that used by pre-7.1 products. The correct algorithm is documented in the 7.2 version of the ESQL/C manual. Informix recommendations: 1. As an initial value, set the FET_BUF_SIZE the same as "b" and then tune from there. To illustrate how the values of network driver size, communication buffer size and fetch buffer size work together, assume the following: - fetch buffer size set to 32K on client - communication buffer ("b") set to 8K on client and server - network driver size of 4K - client application is opening a cursor which will result in more than 32K of data On the server, the first 8K of the result set is placed in the communication buffer. The data in the communication buffer is sent across the network as two 4K packets which are both placed in the 8K communication buffer on the client. This 8K of data from the communications buffer is then placed in the client applications fetch buffer. This process is repeated 3 more times to fill the 32K fetch buffer (requiring a total of 8 packets). The client then sends a "received" message to the server and the data is presented to the application through FETCHes. Once all the data in the fetch buffer is exhausted, the client requests the server for the next 32K and the whole process is repeated. Note - the communication buffer ("b") and fetch buffer parameters will not work with a version 5.x client. ---------------------------------------------------------------------------- Email message 2 .... Here's a summary of how the engine deals will filling packets to be sent to tcp/ip. If there is information to be sent, we will send packets up to the size of 1K. If the rowsize is greater than 1K, it will be broken into two or more packets. The other consideration is the limitation of the TCP "window" on the PC. Some packages have a default size of 512 bytes, so that is something to consider. If the Powerbuilder application is doing some type of a fetch like we spoke about, the engine will use the same algorithm. If the first fetch asks for 100 bytes, we will send 100 bytes in the form of a 1K packet. If the fetch asks for 10 rows of 100 bytes, we will send all 10 rows in a 1K packet. As I mentioned, Inet verstion 5.01.WJ2 is going to implement the FET_BUF_SIZE functionality to allow this 1K barrier to be broken. If you have version 7 tools connecting to version engines, you can use that functionality now. I know this doesn't apply to the Powerbuilder applications, so waiting for 5.01.WJ2 will be the solution for that. ----------------------------------------------------------------------------- On 25 Jul 1996, KeithH0427 wrote: > Hello, > > Can someone tell me what FET_BUF_SIZE actually is and what it does? > > Is this a kernel parameter or part of the onconfig file? It's not in my > onconfig > file and not part of a configurable kernel parameter, but I've been led to > believe > that it will impact performance. We're using HP/UX 10.01 and DSA > 7.12.UC1. > > Thanks in advance, > Keith Howard > Director, CMS Technologies > Reynolds+Reynolds > 708.297.2300 x332 >