Performance tuning / resource management
Recommended reading:
If you wish to protect your service against hardware failure and reach higher
availability of your Ozeki NG SMS Gateway software, we recommend you to try
our Ozeki Cluster software product.
Ozeki Cluster automatically moves any
service to another computer in case of a hardware failure. You can
download it from the following website:
http://www.ozeki.hu/cluster
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.
Introduction
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.
Memory
Symptom:
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.
Figure 1 - Deleting old messages
CPU
Question:
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).
Figure 2 - Disable logging
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.
Figure 3 - Disable persistent message queues.
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
Dig deeper!
People who read this also read...
Next page:
_running_two_Ozeki_NG>Increasing the availability
running two Ozeki NG
| 
