Byte Buffers in SailFin
Throughput, stress and longevity metrics of the SailFin SIP container depends on a few factors that can be controlled and configured by the end user, and getting the right size of the buffers used internally is one of them. Bulk of the work in processing a SIP message involves reading the message (bytes) out of the socket channel and parsing it to frame a valid SIP message. And in a typical IMS (IP Multimedia Subsystems) setup, the application server receives lot of traffic from a CSCF (Call Session Control Function), which is spread across few TCP socket channels. Under these conditions, it is very important to allocate the right buffers for reading/writing the SIP messages. Following is my understanding of how these buffers are allocated.
The Grizzly socket connector used by SailFin associates a byte buffer with each thread (WorkerThread from the ServersThread pool). And this bytebuffer is used to read data from the socket channel. Its important to tune this buffer appropriately so that it does not starve or overflow. The SailFin specific filter that reads the data from the socket channel reconfigures this byte buffer's (which is initially allocated by Grizzly) size to be equal to the socket's receive buffer size. This would ensure that we are able to read whatever has been buffered in the underlying socket's buffer.
The following APIs return the socket's receive buffer size.
((SocketChannel) channel).socket().getReceiveBufferSize(); (for TCP)
((DatagramChannel) channel).socket().getReceiveBufferSize(); (for UDP)
This is a platform specific operation and depends on the socket buffer sizes that have been configured in the operating system.
For e.g On a Suse Linux system the tcp buffer size of the OS can be configured using thr following command (sets to 67MB).
sysctl -w net.ipv4.tcp_mem="67108864 67108864 67108864"
(Please note that though you set the OS tcp buffers to 67 MB, you might see a different value in Java API that gets the receive buffer size)
The receive buffer size optimization is done automatically, and therefore not possible to override this in SailFin There is an attribute in domain.xml that controls this byte buffer size :
But the network manager in SailFin overrides this by tuning the byte buffer to the socket's receive buffer size. So, remember to tune your buffers if your load is high.
The byte buffers that are used to send responses and new SailFin requests (when a UAC), are picked up from a pool. This pool of buffers is initially empty when SailFin starts up and fills up when the demand for buffers (load) increases. This is an unbounded pool of buffers which cannot be configured. Though the pool itself cannot be configured, the size of the byte buffers in this pool can be. Since these buffers are going to hold a sip request/response message, their optimum size depends on the application. One byte buffer is used per outgoing message, and during times of high load the number of buffers in the pool can be in the order of thousands. The default size of this is 8K, and can be configured using the following property in domain.xml
That is pretty much how SailFin uses/manages the byte buffers.