- Product Manual
- SMS technology
- Installation Guide
- User Guide
- Quick Start Guide
- User Interface
- SMS Client software
- Administrator's guide
- Load Balancing for SMPP v3.3
- Manual uninstallation
- Manual upgrade
- SMS server availabilty
- High volume SMS messaging
- Recommended computer
- Manual installation
- Failover cluster on Win2003
- Failover cluster on Win2012
- Migration/Hardware Replacement
- Message priorities
- Message queues
- SMPP via VPN
- Developers Guide
- Examples and Solutions
- SMS FAQ
- Feature list
- Commercial Information
Performance tuning / resource management
This guide gives you information on how to configure Ozeki NG SMS Gateway for high performance and for long term operation. It gives you some information about the internal architecture of the product, to help you understand how it works. The guide covers the following resource management areas: Memory, CPU.
It is important to understand that high performance comes at a cost. A system that can send and receive a lot messages cannot do as much as a system that provides a smaller throughput. To get better performance, you have to give up some comfortable features, such as keeping your messages for a long time in the gateway and detailed logging.
We should also state that a performance of a software largely depends on the underlying hardware. You can increase performance by installing the product to a more powerful hardware. Ozeki NG uses threads and memory. To get better performance it is important to have large amount of memory in the system and it is ideal to run the software on dual or quad core processors or multiprocessor hardware.
Of course we should not forget, that the speed of a software is also effected by other software entities running on the same computer. For example if you have a database server such as Oracle and an SMS server such as Ozeki NG running on the same hardware resources must be shared. It is better to put the two services on different computers (even if you have an SQL SMS gateway configuration). An SMS server communicating with a database server over a high speed network connection can be significantly faster then if the two services are running on the same hardware and are fighting for resources such as memory and disk access.
If you use Ozeki NG for a long time, you might notice, that the amount of memory used is increasing.Reason:
The messages stored in the system are cached in memory for better performance. As you use the system more and more messages and message references will be stored.Solution:
To solve the problem of increasing memory usage, you should configure the system to delete old messages. This will speed up the system and will put a limit to the maximum number of memory used. (To save a long term history of sent and received messages, we suggest you to setup SQL logging.)
To configure the deletion of old messages open the Server preferences form in the Edit menu. Then select Advanced tab and in System health enter a number greater than 0 into the "Delete messages older than" field (Figure 1). I recommend you to keep your messages for 7 days because a returned delivery report can only be matched to the appropriate sent messages if the sent message still exists in the system.
How can I optimize for performance?
Understand what happens:
To optimize your SMS gateway for speed you have to decrease the amount of tasks per message. When Ozeki NG SMS gateway sends an SMS message, the following actions are taken:
1.) The message is accepted for delivery 1/a. It is verified to see if correct message format and correct telephone number format is used 1/b. A log file entry is written to the log file belonging to the user who sent the message mark that the message is accepted for delivery 1/c. The message is saved into the outbox queue. If this queue is persistent the message is saved to the disk. 2.) Routing 2/a. A message is taken from the outbox queue. 2/b. A routing decision is made to select the appropriate service provider 2/c. A log file entry is written into the system event log to mark the routing decision 2/d. The appropriate service provider is selected 3.) The message is sent 3/a. The message is transmitted 3/b. The message reference (callback id) returned by the provider is registered 3/g. A log file entry is written to the log file belonging to the service provider connection 4.) Message delivery is administrated 4/a. The user who sent the message is notified about the "delivered to network" state 4/b. A log file entry is written to the user log file
Do the optimization:
The first (most important) step you should take is to decrease the amount of disk usage. This can be done if you disable logging for the user/application connections, for the service provider connects and for the system itself. Each of these entities have a "Logging" tab on the configuration form. You can disable logging on this tab (Figure 2).
The second step to take is to disable persistent message queues. If the power supply and your hardware is reliable and you can afford to lose messages on power losses, you should disable persistent message queues. If persistent message queues are not enabled, the messages will not be saved to the disk, they will be stored in memory. This saves a lot of time when a message is handled. Persistent message queue handling can be disabled in the server preferences form (Figure 3) if you select Advanced tab. Then in System health you can uncheck this option.
For better performance it is also important to keep your message queues small. The reason for this is that if a message is sent and a delivery report is received it can take a lot of resources to find the appropriate message that was sent if the message queue is very large. You can keep your message queues small if you delete old messages automatically (Figure 1).
In most cases you cannot change the following, but you should know that for performance reasons it is better to:
- Use a smaller number of routing table entries
- Use a smaller number of service provider connections
- Use a smaller number of users/applications
- Ozeki Cluster software
- Failover clustering (Windows Server 2012 R2)
- Failover cluster
- SMS server Backup
- SMS server Automated backup
- Manual SMS gateway uninstallation
- Manual SMS server upgrade
- SMS Service Provider Connectivity
- Users and SMS Applications
- Feature list of the Ozeki NG SMS Gateway
- FAQ of the Ozeki NG SMS Gateway