Planning considerations
Swift MEAP is very flexible, and may be installed on a great many different types of machines with many different options. This guide is intended as a reference for a basic installation. Furthermore, this guide assumes good familiarity with Windows/Linux commands.
Hardware requirements
We recommend a minimum of 2 GB of free memory for your server.
A minimal installation only requires about 1 GB of disk space. The amount of data stored, number of data updates, number of users and the log file size (depending on logging level and time you keep logs) will dictate how large this needs to be. For a small installation, we recommend a minimum of 10 GB of disk space but this will vary from installation to installation. As disk space is relatively cheap, it is recommended that you over-estimate the amount of space required.
Storage
Disk I/O speed often dictates how your server operates. As with all database applications, many read/write operations are performed during normal use. If older, low speed drives are used this can significantly increase the amount of time it takes to complete operations. It is therefore recommended that you install the fastest drives you have available and consider raid arrays to increase performance if you are looking at large volumes of users / data / transactions.
Often, troubleshooting also requires access to the Swift MEAP™ logs. By default, the logs are removed from the server after seven days to preserve space. If users do not notice / report problems for several days, logs may already have been removed from the server. It is therefore recommended that you also implement an archiving strategy so that logs are periodically archived for backup purposes. If issues are discovered, original files can then be retrieved from your archives for investigation.
Networking
As with all applications that require an internet connection, both external and internal influences affect how your system will perform. If the client has a slow internet connection (such as cellular) or is in a poor reception area, this will affect synchronisation / data loads / incremental synchronisation. The client also requires communication between the Swift MEAP™ server and your data source. If there is poor networking performance in any of these areas, overall system performance is affected.
Internal networking / forwarding / router filtering. Many customers use complex networking communication, sometimes using aliased / virtual IP addresses / IP filtering etc. As long as a single addresss from the client can route through your network to the Swift MEAP™ server (and the server can communicate the other way), this is supported. However, the more complex the network, the more routing involved, the longer it takes for requests to be processed.
Data source access. We rely on communication to/from your data source. If your data source is performing badly or takes a considerable amount of time to respond, this will affect the Swift MEAP™ performance.
Security
The server can be configured to use HTTP or HTTPS, it can use a single port for all communication or the adminstration console can be configured on a different port to the client (mobile device) users. Splitting ports allows administrators more control, they can restrict who can access the administration console and it does not need to be on a public URL. Network administrators who are familiar with networking filtering / port forwarding / network configuration may be required to alter these settings.
The server / clients can also be configured so that they only use a VPN. In such cases, access is dependent on the client device supporting the VPN. Not all VPN's have client applications available, you will need to contact your VPN provider for client availablility. Users will be required to login to a separate VPN application on the client devices, they will require access to the VPN before opening the Swift MEAP™ application.
Multiple servers
Swift MEAP™ utilises MySql and Apache Tomcat. Each Tomcat instance can support multiple Swift MEAP™ console applications, so you can install multiple instances on the same physical machine / tomcat instance. However, doing so has some potential drawbacks:
- Each instance will have its own set of jobs running, potentially on different schedules. For example, we poll the data source for all changes since we last connected (usually every 10 minutes). If one server is installed, it is one job reading/writing all changes to disk for all of its users. If you install a second / third / forth server on the same machine you are multiplying the amount of disk I/O operations, as well as the amount of memory required to run separate jobs. If one server has a particulary heavy workload, all server instances could be affected.
- If errors occur on one environment or an update is required to any one of the Swift MEAP™ servers, a Tomcat restart is sometimes required. This is especially true if a server is being upgraded. Some customers wish to keep separate test / production environments. If you want to support both and they are installed on the same hardware, you cannot restart Tomcat in your Test environment without affecting Production users. Usually restart times are small, but it is a consideration that if one is being restarted, all will be offline for a short period.
- Risk of failure. If there is a hardware / operating system / networking issue and multiple servers are installed, potentially all users of all servers are affected.