Table of Contents

Performance (TPS)

The achievement of Transactions Per Second (TPS) in SMPP processing is influenced by several factors, including hardware specifications, software efficiency, network conditions, and the specific implementation details of your application. Here are some key considerations:

  1. Hardware Specifications:
  • CPU: Utilize a multi-core processor with a high clock speed to handle the often CPU-intensive SMPP processing efficiently.
  • Memory (RAM): Ensure sufficient RAM to manage message processing effectively. The SMPP client typically retains the request Protocol Data Unit (PDU) in memory until the appropriate response is received and processed.
  1. Network Infrastructure:
  • Bandwidth: Ensure that the server has enough network bandwidth to handle the volume of messages you expect.
  • Latency: Low network latency is crucial for fast communication between the SMPP client and the SMPP server.
  1. Application Implementation:
  • The efficiency of the software is critical. Ensure it is well-optimized to handle a high volume of transactions.
  • Fine-tune the configuration of the SMPP client to maximize performance.
  • Minimize the time taken for message preparation.
  • Determine the optimal message batch size.
  • Process requests and responses as quickly as possible.
  1. Monitoring and Tuning:
  • Continuously monitor the application performance during testing and production.
  • Use monitoring tools to identify any bottlenecks and optimize configurations accordingly.
  • When starting, use SmppClientDemo application to estimate single SMPP session performance with a SMPP server.
  1. SMPP Server:
  • Consider that achieving high TPS may depend on the capabilities and limitations of the SMPP server you are connecting to and the overall SMS infrastructure.
  • Use Metrics to measure the response time of the SMPP server, helping you analyze its performance.

Local Test

Performance testing of Inetlab.SMPP on the local machine with logging disabled shows the following result:

Performance: 20356 m/s 

The following code demonstrates this:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Net;
using System.Threading.Tasks;
using Inetlab.SMPP;
using Inetlab.SMPP.Common;
using Inetlab.SMPP.Logging;

namespace TestLocalPerformance
{
    internal class Program
    {
        private static void Main(string[] args)
        {

            LogManager.SetLoggerFactory(new ConsoleLogFactory(LogLevel.Info));

            StartApp().ConfigureAwait(false);

            Console.ReadLine();
        }

        public static async Task StartApp()
        {

            using (SmppServer server = new SmppServer(new IPEndPoint(IPAddress.Any, 7777)))
            {
                server.evClientBind += (sender, client, data) => { /*accept all*/ };
                server.evClientSubmitSm += (sender, client, data) => {/*receive all*/ };
                await server.StartAsync();

                using (SmppClient client = new SmppClient())
                {
                    await client.ConnectAsync("localhost", 7777);

                    await client.BindAsync("username", "password");

                    int testResult = await RunTest(client, 50000);

                    Console.WriteLine("Performance: " + testResult + " m/s");
                }
            }
        }

        public static async Task<int> RunTest(SmppClient client, int messagesNumber)
        {

            List<Task> tasks = new List<Task>();

            Stopwatch watch = Stopwatch.StartNew();

            for (int i = 0; i < messagesNumber; i++)
            {
                tasks.Add(client.SubmitAsync(
                    SMS.ForSubmit()
                        .From("111")
                        .To("222")
                        .Coding(DataCodings.UCS2)
                        .Text("test")));
            }

            await Task.WhenAll(tasks);

            watch.Stop();

            return Convert.ToInt32(messagesNumber / watch.Elapsed.TotalSeconds);

        }
    }
}

It's important to note that the performance test should always be started without an attached debugger, and the application should be built with the Release configuration.

The performance result obtained in the local test represents the maximal throughput achievable on the machine under the given conditions.