EMG 6.0.6 - User's Guide

Table of ContentsPreviousNext

14. Performance

Performance is usually on top of the agenda when discussing product capabilities. We start out by defining high performance in the EMG context as the ability to process more than 100, even up to 5.000, messages per second. By processing we mean that a message is received, potentially converted and re-transmitted.

EMG is a very efficient platform using several different mechanisms in order to achieve this effectiveness and high performance:

EMG is multi-threaded as opposed to multi-processed
Threading is a much more efficient way to perform multiple simultaneous tasks than using traditional operating system processes. Creation, destruction and task-switching using threads is at least 100 times more efficient than the same procedures for processes.
EMG encourages use of persistent connections
The amount of overhead introduced by each connect, login, logout, disconnect is huge on a high-performance system.
EMG implements efficient queue algorithms
Often a system-wide queue or point of synchronization can be a bottleneck and turn out to severely degrade system performance. The EMG design and implementation of queue effectively addresses this.

14.1 Hardware and operating system

First of all we want to make clear that EMG can process 100+ messages per second on more or less any hardware that runs the supported operating systems. If you have an EMG server licensed for 10 mps hardware performance is not an issue. This often means that other criteria than performance can be the determining factor for the choice of hardware. For example, in some cases less expensive low-end hardware which can be easily replaced would be preferable while in other cases a high-end server with built-in redundancy would be a better choice.

14.1.1 CPU

EMG is very CPU intensive when processing many messages per second and a 50% faster CPU will give a close to 50% better result in performance.

14.1.2 RAM

Each message takes up a certain amount of RAM. For example, 100.000 messages in queue would need approx 150 MB of RAM. If DLRs are used the amount increases to approx 450 MB of RAM.

14.1.3 Disk

Disk space should be sufficient to handle log files. In order to limit disk space used by log files it is possible to use log file rotation based on size. See the ROTATELOGS general keyword.

14.1.4 Operating system

With later versions of EMG there is little difference between different OS versions on comparable hardware.

14.2 Protocols

The different protocols supported by EMG delivers different performance. Specifically EBE and MGP are not to be used for high-performance applications. The EBE protocol forwards messages to external programs or shell scripts and for each message a process is forked in the system. EBE connectors typically delivers a maximum of 20-200 mps when forking a shell script, 40-400 mps for a Perl script and 80-800 mps for a custom binary. The proprietary protocol MGP is designed for ease of use, monitoring the EMG server etc and it is not intended to be used for high-performance applications.

All other protocols (CIMD2, SMPP, OIS, UCP/EMI, HTTP, SMTP) are capable of handling hundreds, or even thousands, of messages per second.

14.3 Instances

Each active connector can be available in one or more instances. The number of instances should be kept to a minimum and in an ideal world with one system sending messages to EMG over a persistent connection and one system receiving the message one incoming and one outgoing instance would be enough.

However, for incoming connectors you may have more than one system that needs to connect to EMG. The number of instances controls how many simultaneous connections EMG can accept. Also if a connection is terminated abnormally, network outage or similar, the instance session may not be cleared before a new connection attempt is made. Therefore the number of instances for incoming connectors should be at least the number of expected simultaneous incoming connections plus a few spare ones. If you expect one incoming connection you should allocate 5 instances.

Please note that there will be a limited number of threads available in the operating system (1024 is the default value for RedHat Linux 7). Each connector instance will use up to two threads, one for reading and one for writing. This will in practice limit the maximum number of instances that can be used in the system.

Running the command "emgd -threadcount" will count and display the maximum number of threads that can be created by a single process.

14.4 Other issues

14.4.1 Modifying message content

The only way to modify message content in EMG 1.x was to use an intermediate EBE connectors which affects maximum throughput severely. In EMG 2.5 this can be done using mappings where even a complex mapping may affect performance only by 15-20%. From EMG 3 the EMG Plugin API can used in order to implement advanced functionality in-process using a shared library which will impose a minimal overhead.

14.4.2 Server logging and debug mode

The logging in EMG is handled by a separate thread and therefore is very efficient. However, if the queue of log events builds up quicker than it can be flushed to disk it will consume RAM, I/O and ultimately CPU resources. Specifically, when running the EMG server, emgd, in debug mode, "emgd -debug", the impact on performance is severe.

14.5 About benchmarks

When performing benchmarks and load testing in order to verify that EMG delivers to its promise it is important to first of all make sure that the tools used are designed for the performance they are supposed to measure.

There are numerous tools freely available that are capable of measuring performance up to 10-20 mps but not more than that. For example an SMTP load tester that do not use persistent connections will not be able to measure the full capabilities of EMG.

We recommend our own load generation tools, emgload and emgsink, which are freely available from http://www.smpp.com/smpp-benchmarking.html.

Table of ContentsPreviousNext