Achieving high throughput
memaskal opened this issue · 6 comments
Hello, I am using camel with the SMPP component and by studying the implementation of this lib I came up with the function org.jsmpp.session.SMPPSession#submitShortMessage. From my understanding, this is used to send the submit_sm to the SMSC and synchronously wait for the response (submit_sm_resp).
My question is how someone would approach the high rates advertised when each request to send a message waits for its response? Moreover what happens when the SMSC can support more than 1 outstanding request per session! Would this mean that I would need to have multiple threads per session?
Do you have any insights on how someone would solve the above issues using the Camel SMPP component since the session is tied to the producer?
Yes, submitShortMessage will send an submit_sm request to the remote side. The higher rates are achieved by using a higher window size. When using a window size of 1, will lead to low bandwidth, as the request indeed will have to wait for the response, before sending the next request. When for example, you implement a window size of 100, you are allowed to send 100 requests at once, without having received the response. When sending the next, a request should have received the response and freed 1 window. So 100 requests can be then active at the same time. Normally the SMSC will decide the window, the SMSC knows it's capacity. 1 session can handle more requests. The session can be prepared with the setPduProcessorDegree() and setQueueCapacity(). The default is 3 threads to handle the messages and a queue of 100.
The Camel SMPP (https://camel.apache.org/components/latest/smpp-component.html) says:
Some SMSC providers implement throttling rules. Each part of a message that has been split may be counted separately by the provider’s throttling mechanism. The Camel Throttler component can be useful for throttling messages in the SMPP route before handing them to the SMSC.
The SMPP 5 specification has some paragraphs on it: Flow Control and Congestion Avoidance
Did you receive low bandwidth with Camel ?
Hello @pmoerenhout and thanks for your quick reply.
I haven't run into performance issues yet, but I see that my session is underutilized. Yes, my SMSC uses a window size > 1 and enforces a rate limit on segments (as the CAMEL docs suggest), by using a fixed window_size.
By checking the implementation of the Stress Client Example I see that an Executors.newFixedThreadPool is used with the maxOutstanding number of threads (window size) to ensure that the full window size is utilized.
If I would like to implement an output_window = X ( jsmpp ->SMSC) and an input_window = Y (SMSC <- jsmpp) what parameters should be altered on the JsmppSession ? What is the effect of the processor degree, would I need to create the
threads myself to utilize the output_window size ?
Finally, when it comes to Camel, do you have any experience with how to alter these parameters?
I made a Camel application which sends asynchronous messages. I could come to approx. 140 msg/sec when connecting to a remote server, and to approx. 8000 msg/sec when connecting to localhost. What performance do you get ?
By default of the input and output queue capacity is set to 100. The processor degree determines the number of processing threads. Normally 3 threads should be sufficient to handle the incoming responses, i.e. when you handle the backend processing async.
Hello @pmoerenhout can you please share, your Camel implementation, so I can see how you did implement the asynchronous messaging?
So, in order to utilize an output_window (i.e 10) I would need to set the processor degree >= 10 ? Since each thread would retrieve a message from the output queue and try to send it to the SMSC, so I can achieve a maximum of 10 outstanding requests?
I have create it at https://github.com/pmoerenhout/camel-spring-boot-smpp. I see that the processorDegree (default 3) and the QueueCapacity (default 100) session parameters are not manageable from Camel. If needed I can create that, but locally I can reach 8000 msg/sec. So I expect any lower number is due to the SMSC not keeping up with the pace.