The time involved in transferring a large message (of size M) is the sum of the time involved in:
- transferring N JMS Messages of size M/N.
- I/O operations (reading the large file on the sender side + saving the large file at the receiver end)
- establishing the connection and ensuring fragment sequence and reliability.
The following factors can affect the performance of LMS.
Fragment Size
A small fragment size implies frequent I/O operations (reading the source file and saving the target file) as well as frequent socket calls to send the fragments to the server. Large fragment size implies increased memory usage both at the client and server ends. The optimal fragment size should be small enough to be held in the memory of the sender, server, and receiver. Fragment sizes, whether small or large, should be in multiples of TCP/IP packet size for deriving optimal performance.
Window Size
A large window size implies increased memory usage at the server end because of the possibility of the receiver being slow to receive the messages from the server. After a window of fragments is sent, the message producer halts itself to receive an acknowledgment from the server. The receiver can not receive a fragment sequentially and request the fragment to be sent again. It is wise to have smaller window sizes when the expected rate of fragment loss is high. Another factor to be considered is the latency between the sender and the receiver. It is better to have a large window size when the latency is high.
Status message frequency
The setLMStatusListener call registers a status listener with the message transfer and informs the user application of the status of the message transfer. It also takes another parameter for the frequency of status updates required by the user. The value of this parameter is the number of windows of message fragments sent before the user application is updated to the status of 'transfer'. A small value (say 1, for an update after every window) hampers the message transfer rate considerably. Performing intensive operations in the onLMStatus call takes up considerable time by the message transfer thread.