Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Meridix

...

platform - Hosting & scaling

Introduction

Meridix Studio Platform is used by small companies with less than ten users as well as by large companies, telecom operators and goverment government authorities with thousands of users. Therefore its crucial to allow a Meridix installation to scale depending on the size of the customer, both to be able to give users great performance but also to keep hardware and hosting costs down for customers that wouldnt wouldn't get any benefits from an high-end server environment because of their small size.
Its also important for a system to be able to increase or decrease its computing resources in the future if the number of users change and not force customers to take height in advance which would result in unnecessary costs upfront.

...

Below is descriptions of how we could handle two different scenarios, but each case is unique and we always evaluate each customers needs to give them the best solution with the lowest cost for their requirements.

Scenario: Smaller customers

In these cases we usually have two servers that is load-balanced to share the load, the main reason to have more then one server in these cases is not to get any performance benefits but to have redundancy of the application i.e. if one server fails or updates/patches the OS the other one is still available and can serve users. The partitioning of servers sizes (memory, CPU etc) depends on the size of the customer. (A reason to keep them as small as possible is to keep costs down for the customers).

In these cases the report distribution responsibility is shared by the servers so a server handles both the web UI and the report distribution.

Scenario: Larger customers (e.g. Telecom operators/carriers)

In these cases we usually have atleast at least three servers where two servers is dedicated for handling the web UI and one additional servers that handles the report distribution. In addition to the benefits described in the previous section this setup allows a system to not be affected by spikes in the report distribution queue (e.g. if almost all users have reports that should be sent the first day every month) the web UI is not affected by the fact that the number of queued reports is large at that time and that the distribution service/agent has a high load.
If a customer has many concurrent users but fewer scheduled reports we can increase the number of web servers or if the customer have a large number of scheduled reports we can have multiple report distribution services/agents that handles the queued reports.