severe slowness while processing large number of DELIVER_SM PDUs at a time through SMPP Receiver Bind

[balakrishnavalavala]

Hi Team,

    We are facing severe slowness while processing large number of DELIVER_SM PDUs at a time through SMPP Receiver Bind.

Detailed Issue description:

=====================

1) We are targeting around 1.3 Million MT records (SUBMIT_SMs) in the time frame of around 5 hours and they are successfully reaching to customers in that 5 hours timeframe and no issues in it. Here our mta settings are like, 1 MTA child connection and 4 MTA Childs i.e. (total 5 tx binds and 1 rx binds).

2) When we started receiving the DELIVER_SMs for above SUBMIT_SMs, it is taking minimum 1 or 2 days to process those 1.3 M records's Delivery Receipts and MOs.

3) Because of this slowness in Deliver_SMs, reponse to MOs kept in queue and waiting until the Deliver_SMs (to update the statuses) process to complete.

4) Because of above issues, customer is receiving the MO responses in odd timings like mid nights/early mornings and expressing some concerns about it and showing interest to unsubscribe the services. 

Based on above points, you might have understood our concerns that why the DELIVER_SMs are processing very slow at Adobe side an dhow to fix it.

Your solutions will definitely help us along with all the users here who is using SMPP protocol as part of SMS channel.

We are eagerly waiting for your valuable responses and also ready to provide what ever information you need from our end for analyzing this issue.

Thanks

[Shubham_Goyal__]

Hi @balakrishnavalavala ,

To reach the maximum possible throughput, you will need to fine-tune the maximum sending window. (The sending window is the number of SUBMIT_SM PDUs that can be sent without waiting for a SUBMIT_SM_RESP.)

So, check out your "Throughput and timeouts" settings in your SMS external account as these settings control all the timing aspects of the SMPP channel. Some providers require very precise control of the message rate, window, and retry timings. These settings should be set to values that match the capacity of the provider and the conditions indicated in their contract.

Check out this to seek more info to increase SMS throughput: link

Br,

Shubham

[balakrishnavalavala]

Hi Shubham,

     Thank you so much for your response. Here we have no issues in SUBMIT_SM PDUs and their throughputs and timings but will consider your valuable points related to TX binds or MTs.

And as mentioned in above description, our main issue is slowness in processing the Delivery Receipts (DRs i.e. Deliver_SM PDUs) and also MOs related DELIVER_SMs. If you still linking this issue with sending windows then could please provide us little more information to understand it better.

We are actually thinking that there might be some DB related performance tuning needs to be done to fix the this slowness while processing Deliver_SM PDUs. Please provide your suggestions here as well.

Thanks

[Shubham_Goyal__]

Hi @balakrishnavalavala ,

Alright, if the problem is just with importing the MO & SR's sent from your SMPP provider then it's worth checking the problem from the DB side (sending window will have no role to play for incoming sms's). All the incoming MO's and SR's are stored directly in the inSMS table of the Adobe campaign and once the data is stored an acknowledgment is sent by the Adobe campaign (_RESP).

So, points you can check on your side:

-If the inSMS table or entire DB is bloated and if this needs partial/full vacuuming.

-If there are any DB locks on the inSMS table.

-If there are any errors you observe in the inSMS table when processing data?

Br,

Shubham

[balakrishnavalavala]

Hi Shubham,

    Thank you so much for the above valuable suggestions related to slowness. Here we have a thought about vacuuming but our RDBMS is Oracle, where vacuuming concept is not applicable as far as we know and DB related performance tuning is going fine from our daily 4:00 AM Database Cleanup workflow. And also locks and errors was not occurring based on our observations from sms.log files.

And one more thing we need to note here is that MOs count is less when compare to broadlog status updates (SRs) back for all the targeted recipients and these SRs blocking the MOs and placed in queue until it's turn comes to insert into insms schema. 

Will increaseing RX binds solves this issue? At present we kept only 1 RX bind connection.

We also observed that broadlog schema updates were stopped happing after some large update transactions happened through sms module. We can say that it went in to hung state related to broadlog updates until it's next day auto restart at 6:00 AM and after the restart, updates on broadlogs getting resumed.

Could you please provide your valuable suggestion from here and are we missing any important things? And how are you dealing your SMS channel using SMPP for large targets like above?

If you are fine then could we please personally connect? Here is my Gmail address: balakrishna.valavala@gmail.com and please email to this with your personal contact information.

Thanks

[Sukrity_Wadhwa]

Hi,

Kindly share the solution of this query here with the Community as well to help fellow users facing same kind of issues.

Thanks!