Meridix Studio scaling

Introuction

Meridix Studio is used by small companies with less than ten users as well as by large companies, telecom operators and goverment 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 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.

Meridix Studio is built to allow an installation to scale both up (more computing power) and down (less computing power) as well as out (more servers) and in (less servers).
The nature of reporting can also give spikes in the usage of the system, for example in the beginning or end of each month etc. and in these cases its even possible to spin up more servers/agents at these peek times. 

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)

In these cases we usually have atleast 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.