Docs: adding some clarification into a manual that are not clear

[vetss]

Let's add here comments (for examples from customer requests) that we will add to the manual

[vetss]

Question for "what configuration parameters influence/improve the traffic throughput"

• We have two possible message flow type. 1) when a message is firstly stored into a cassandra database - StoreAndForward mode (when "smsc get storeandforwordmode" is set to "normal"), 2) when a first delivery retry is done without storing a message into a cassandra database - datagramm, Transactional, ForwardAndStore. If you have some high traffic load you can try scenario "1)". In this case when a message highload peaks cassandra will store messages befor delivering and all incoming messages will be accepted (but this may lean some delay before the first delicery attempt). In scenario "2)" if there are many messages in processing then some incoming messages will rejected by SMSC GW with "STATUS_THROTTLED" cause (for SMPP case). And SMPP application must be ready to resend such rejected messages later. If SMPP applications can not do so, then it is better to use "1)" scenario.

Currently we have the JVM initial and maximum heap size set to 3GB.

we recommend to use up to 4GB for JAVA heap. More heap size will lead of more GarbageCollector work. But you can try more size and check behavour. I suppose you use 64-bit JAVA.

And are there other Telestax SMSC configuration parameters which influence the traffic throughput?

Please check "6.1.4.1. Fetch Period (in ms)", "6.1.4.2. Max Rows" and "6.1.4.3. Max Activity Count" chapters. "maxactivitycount" parameter specify how many messages will be processed at the same time. If you have high productivity server then you can try to increase it. But be carefull - if you increase it too high then the it leads the productivity reducing because of SMSC GW will not be able tp process all together.

For monitoring you can use "8.1. View SMSC Statistics" - "8.1.1. Using CLI" manual. DueSlotProcessingLag output said of if SMSC GW is overloaded (you will see that this parameter be encrased permanemtly in this case).

For example in the configuration of SCTP layer in the SS7 stack, we see the parameters "SingleThread" (default "true"), and "WorkerThreads" , which should be equal to the number of CPU's in case multi-threading is used (SingleThread=false). What is the recommendation here, single threading (currrently used) or multi-threading?

please leave "SingleThread" as "true". The count of therads that will process incoming SS7 messages - you can try to increase of one parameter (if you use m3ua (sigtran)):

• open file jboss/server/default/deploy/telscale-smsc-server/META-INF/jboss-beans.xml in the text editor
• find "bean name="Mtp3UserPart"" mbean definition
• increase "1" to some value like "processor count * 2"

And on the SMPP side we have the parameters "DefaultWindowSize" and "MaxConnectionSize" (default 100),

you can increase it if you see that you have bottleneck at SMPP side. For your model when all messages go "SMPP->SMSC GW->SS7" you will find such overflow if SMSC GW is not overflowed but ESME application can not send extra messages to SMSC GW. I do not know how we can measure this part (SMPP part).

[vetss]

Tips: "how to start the SMSC GW process at background"

• we can use "screen" linux command - we need to describe some base commands how to run / show it

[vetss]

• a command how to check if SMSC GW instanse is run (ps -ef | grep jboss) - if we run several instanses the second instanse will have records in the logs like "BindException: Address already in use".

[vetss]

• we need to add info of cassandra database parameters update for high loaded systems (in the file cassandra.yaml):
  • tombstone_warn_threshold: 1000 -> 5000 (in case of warning like "Read 386 live and 1496 tombstoned cells in system.schema_columns (see tombstone_warn_threshold).")
  • read_request_timeout_in_ms 5000 -> 25000 (or twice more to prevent timeouts in case when we have very many paending message to one destination)
  • range_request_timeout_in_ms 10000 -> 50000 (same)
  • request_timeout_in_ms 10000 -> 50000 (same)

[vetss]

Fixed by:

https://github.com/RestComm/smscgateway/commit/aaee3ce1741a516ca957d35df9f415ca09bde28c