Welcome, Guest Login

Support Center

Server and Hardware Configuration Considerations

Last Updated: Aug 15, 2016 12:48PM EDT

Hardware Considerations
Server and Hardware Configuration Considerations

Table of Contents



Server Roles

Momentum is deployed as several distinct “roles”, each providing different functionality of the Momentum Solution. The available roles are:

  • Platform Role

    • MTA - Supports all Message delivery functionality including Adaptive Delivery. Optionally, also supports Message Generation.

    • Platform DB - Stores all templates, recipient lists, and generation task data.

    • Event Hose – Distributes all system events to the Analytics node and Webhook subscriptions.

  • Analytics Role

    • Analytics DB – Stores aggregated data of all system events delivered by the event hose.

    • Web User Interface – Provides graphical reporting summaries, template editing and management, recipient list storage management, and authentication key generation and management.

    • HTTP Proxy Service - Supports all REST API including message generation, administration, and metrics (reporting) functions.

You do not need to install all roles. Also, some sub-roles can be deployed on separate nodes. Listing all possible permutations is not feasible. Please consult with a Momentum Product Manager for more information on highly distributed deployments.

Configuration Options

Momentum enables you to create standardized cluster configurations with hardware specifications appropriate for different levels of messaging capacity. You can deploy Momentum in multiple configurations to meet specific performance and operational requirements. Consult with your Message Systems account team to address requirements not covered here.


Hardware Scaling Approach

Although you can deploy hardware capable of processing over five million messages per hour, it is not cost effective to do so if that volume level is not required. This section will provide guidance on deploying the appropriate level of hardware resources to support different volume levels.

Environmental Considerations

Momentum can send very high volumes of traffic; however, it can be constrained by external systems in the deployment environment, such as network throughput. You should consider the impact of Momentum traffic volumes on your environment.


External Network Bandwidth

You must consider the total bandwidth required to support your traffic volumes. A single node can readily saturate a one Gbps Network Interface Card (NIC). This is accounted for in the configurations specified below. It is also important to consider the total volumes of the entire cluster. It is possible to saturate a one Gbps network. It should also be noted that larger message sizes saturate available network bandwidth more quickly than smaller message sizes. Depending upon your expected message size, this can be an extremely important consideration when calculating rough estimates of required network bandwidth.



Momentum’s queuing architecture allows delivery over hundreds or even thousands of parallel connections. Furthermore, Adaptive delivery rules allow for multiple parallel connections to receiving ISPs. Momentum takes full advantage of parallel connections to maximize delivery throughput. Firewalls need to support high connection volumes and bandwidth requirement of the total volume. Additionally, the firewall should not be stateful as firewalls are not able to keep up with the session management.

Internal Network Bandwidth

When sending transactional or SMTP traffic into Momentum, the injection network must match the bandwidth of the external network.


Additional Configuration Notes

File System

Momentum writes a copy of every message to the spool disk to assure no loss of messages. Sending at high volumes requires sufficient disk IOP capacity, particularly for the spool disk. Message Systems recommends the use of ext4 file systems. You can also use SANs or network attached file systems; however, these storage options introduce additional network IO and latency that can degrade performance. Make sure you account for this additional network traffic or consider a separate network for the storage components.

Memory Speed

Momentum is a memory and CPU intensive application. For optimal performance, the system memory must operate at 1866 MHz or faster.

Network Interface

Ensure that you are running on a kernel that is 2.6.18-194 or newer. This will help you avoid bugs that were found in previous Linux kernels related to Broadcom NICs. Also, if you build custom kernels, review RedHat bug numbers 587799 and 581148 for more information.


Momentum does not require the creation, modification or access times on either the data or metadata files to be correct (or maintained). So mounting a volume with the noatime mount option will greatly reduce the number of unnecessary disk accesses. The spool array should be formatted using either the ext2 or ext4 file system. ext2 and ext4 have comparable performance, with ext4 being considered more reliable (because of journaling). ext3 can slow down performance, so is not recommended. Set the following options in your fstab:



LABEL=/var/spool/ecelerity /var/spool/ecelerity ext2 rw,noatime 0 2


LABEL=/var/spool/ecelerity /var/spool/ecelerity ext4 rw,noatime,barrier=0 0 2

RAID Arrays should be configured only in RAID1 or RAID10 configurations. The Momentum software maintains a very high write load that is not suitable for a RAID5 array; therefore, RAID5 is not supported.


Momentum performance testing is executed on physical (non-virtualized) servers. If you run Momentum in Amazon Web Services (AWS) or OpenStack environments, or in other common virtualized environments such as VMware, you should plan for a potential loss of 20% - 30% in performance.

  Introduction Next Article
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found