Once the message is in the access log it has passed opensmppbox already.
So if throughput is slow, maybe it's your downstream smsc connection.
------ Origineel bericht ------
Van: "garz m" <garz...@gmail.com>
Aan: users@kannel.org
Verzonden: 30-3-2017 10:24:54
Onderwerp: Opensmppbox Slow Response (submit_sm_resp)
Dear Rene / Users:
Good day!
I'd like to consult to you our experience using Kannel Opensmppbox.When
an ESME sends large TPS traffic, we noticed slow response from the
Opensmppbox app, thus creating a queue at the ESME's end. I have here
sample PDUs:
Submit_SM PDU
==============
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP[]: Got PDU:
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP PDU 0x7fe24d4a77c0 dump:
2017-03-27 14:59:13 [1641] [30] DEBUG: type_name: submit_sm
2017-03-27 14:59:13 [1641] [30] DEBUG: command_id: 4 = 0x00000004
2017-03-27 14:59:13 [1641] [30] DEBUG: command_status: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sequence_number: 4488803 =
0x00447e63
2017-03-27 14:59:13 [1641] [30] DEBUG: service_type: NULL
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr_ton: 5 =
0x00000005
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr_npi: 0 =
0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: source_addr: "xxxxxxxx"
2017-03-27 14:59:13 [1641] [30] DEBUG: dest_addr_ton: 1 = 0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: dest_addr_npi: 1 = 0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: destination_addr:
"xxxxxxxxxxxx"
2017-03-27 14:59:13 [1641] [30] DEBUG: esm_class: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: protocol_id: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: priority_flag: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: schedule_delivery_time: NULL
2017-03-27 14:59:13 [1641] [30] DEBUG: validity_period:
"170329065905000+"
2017-03-27 14:59:13 [1641] [30] DEBUG: registered_delivery: 1 =
0x00000001
2017-03-27 14:59:13 [1641] [30] DEBUG: replace_if_present_flag: 0 =
0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: data_coding: 0 = 0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sm_default_msg_id: 0 =
0x00000000
2017-03-27 14:59:13 [1641] [30] DEBUG: sm_length: 103 = 0x00000067
2017-03-27 14:59:13 [1641] [30] DEBUG: short_message:
2017-03-27 14:59:13 [1641] [30] DEBUG: Octet string at
0x7fe24d342720:
2017-03-27 14:59:13 [1641] [30] DEBUG: len: 103
2017-03-27 14:59:13 [1641] [30] DEBUG: size: 104
2017-03-27 14:59:13 [1641] [30] DEBUG: immutable: 0
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xxxxxxxxxxxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: data: xx xx xx xx xx xx xx
xxxxxxx
2017-03-27 14:59:13 [1641] [30] DEBUG: Octet string dump ends.
2017-03-27 14:59:13 [1641] [30] DEBUG: SMPP PDU dump ends.
Submit_SM_Resp PDU:
==================
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP[]: Sending PDU:
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP PDU 0x7fe24d34a6d0 dump:
2017-03-27 14:59:39 [1641] [29] DEBUG: type_name: submit_sm_resp
2017-03-27 14:59:39 [1641] [29] DEBUG: command_id: 2147483652
<tel:(214)%20748-3652> = 0x80000004
2017-03-27 14:59:39 [1641] [29] DEBUG: command_status: 0 = 0x00000000
2017-03-27 14:59:39 [1641] [29] DEBUG: sequence_number: 4488803 =
0x00447e63
2017-03-27 14:59:39 [1641] [29] DEBUG: message_id:
2017-03-27 14:59:39 [1641] [29] DEBUG: Octet string at
0x7fe24d341f30:
2017-03-27 14:59:39 [1641] [29] DEBUG: len: 36
2017-03-27 14:59:39 [1641] [29] DEBUG: size: 37
2017-03-27 14:59:39 [1641] [29] DEBUG: immutable: 0
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 32 32 39 64 62 39 32
63 2d 35 37 61 63 2d 34 33 229db92c-57ac-43
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 34 35 2d 61 64 34 66
2d 36 61 35 65 65 39 66 31 45-ad4f-6a5ee9f1
2017-03-27 14:59:39 [1641] [29] DEBUG: data: 66 62 39 30
fb90
2017-03-27 14:59:39 [1641] [29] DEBUG: Octet string dump ends.
2017-03-27 14:59:39 [1641] [29] DEBUG: SMPP PDU dump ends.
Looking at the Bearerbox Access logs, i found that this sample was
processed right on time:
Access Logs (CDRs)
2017-03-27 14:59:14 Sent SMS [SMSC:HTTP.SMSC] [SVC:xxxxxx] [ACT:]
[BINF:] [FID:229db92c-57ac-4345-ad4f-6a5ee9f1fb90] [META:?smpp?]
[from:xxxxxxxxxxx] [to:+xxxxxxxxxxx] [flags:-1:0:-1:0:19] [msg:103:]
2017-03-27 14:59:19 Receive DLR [SMSC:HTTP.SMSC] [SVC:xxxxxx] [ACT:]
[BINF:] [FID:229db92c-57ac-4345-ad4f-6a5ee9f1fb90]
[META:?orig_msg?dlr_mask=19&] [from:xxxxxxxxx] [to:+xxxxxxxxxxxx]
[flags:-1:-1:-1:-1:1] [msg:0:] [udh:0:]
Also, DB table check confirmed that indeed the transaction was
processed on time:
DB Sent_SMS
+---------------------+------+--------------------------------------+---------------------------------------------------------------------------------------------------------+
| from_unixtime(time) | momt | dlr_url |
msgdata
|
+---------------------+------+--------------------------------------+---------------------------------------------------------------------------------------------------------+
| 2017-03-27 14:59:13 | MT | 229db92c-57ac-4345-ad4f-6a5ee9f1fb90 |
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
| 2017-03-27 14:59:19 | DLR | 229db92c-57ac-4345-ad4f-6a5ee9f1fb90 |
NULL
|
+---------------------+------+--------------------------------------+---------------------------------------------------------------------------------------------------------+
These logs, for me, is clear that opensmppbox response is slow for the
submissions from ESME's.
Our setup by the way is this:
ESME <=> Opensmppbox <=> SQLBox <=> Bearebox <=> HTTP SMSC
I hope you can take a look about this case.
Thank you and looking forward to your comments.
Kind regards,
Garzie
