I’m copying the contents of the servline24 document 45608.
[i]Below is information from the EntireX Documentation on the poolsize and pooltimeout parameters, followed by information from Development on how these settings might effect performance.
From the EntireX v6.1.1 Developer’s Kit documentation:
Java ACI / Java System Properties and Socket Parameters / Socket Parameters for TCP and SSL Communication:
The behavior of the socket pooling can be influenced by two parameters specified as part of the Broker ID. They are used for both TCP and SSL communications. The parameter poolsize specifies the maximum number of socket connections which are kept in the socket pool. If that number is reached, further Broker calls going through a Broker instance are delayed until a socket becomes available. If a multi-threaded application uses blocking sendReceive or Receive calls with a longer waiting time, the poolsize parameter must be at least equal to the number of threads. The default value for the poolsize parameter is 32. Setting the poolsize parameter to 0 disables the socket pooling. The behavior is then identical to that of the pre-6.1.1 versions of EntireX.
Automatic closing of socket connections is controlled by the parameter pooltimeout. If a socket connection has not been used for the specified the number of seconds it will be closed automatically. The default for this parameter is 300 seconds.
Example for using a maximum of 10 socket connections and a timeout of 60 seconds:
Broker broker = new Broker(“yourbroker?poolsize=10&pooltimeout=60”,“userID”);
Supplemental information from Development:
The poolsize/pooltimeout parameters are parameters used by the EntireX Java ACI/RPC runtime. They determine the maximum number of socket connections from the Java application to the Broker; and the time of nonactivity on a Socket until the socket will be closed.
Please note that a socket (from the pool) is not allocated to each user. A socket is retrieved from the pool only for the duration of a Broker call. After the Broker call returns, the socket is put back to the pool and may be retrieved for another user.
In case of a web scenario it can be assumed that 100 simultaneous users do not issue Broker calls permanently without delays. In that case the default 32 seems to be a good choice. It should also be noted that increasing the number of socket connections will only increase the throughput if enough server replicates are available.
Regarding the pooltimeout: there is no blocking on a socket. The open question is how many other applications are talking to the Broker using TCP/IP and if there are limitations, are performance problems either in the TCP/IP stack or in the TCP/IP communicator of the Broker when too many socket connections are open.
Let me try to reformulate the last part.
The pooltimeout specifies the time (how long) a socket connection will stay alive without any activity. The socket can be reused from the Java application when necessary so it is not blocked, but it is unused.
There is no simple answer to the question if the pooltimeout should be short or long. If the pooltimeout is short, sockets will be closed when there is no activity and need to be reallocated when new requests are coming in. On the other hand, each established socket connection to the Broker uses Broker resources (memory). The customer needs to consider the number of (client or server) applications which communicate to the Broker via TCP/IP. [/i]
Please let me know if you have further questions.
