In this article
In this part of the documentation we have provided some examples for Forsta Plus server and infrastructure scenarios for different requirements relevant to the points given here. The examples show how Forsta Plus can be an easily maintainable application running off a server, and how it via different scenarios can evolve into a fully-fledged enterprise solution. The scenarios presented are only meant as examples, and are not absolute. Furthermore, they are deliberately conservative, and real capacity should exceed the outlined calculations. Other combinations of modules than those listed here are of course possible. Forsta Technical Support can help design the site based on your requirements; please contact Forsta Support or your Account Manager for more information.
Basis for Setting Up the Recommendations
When setting up site recommendations for customers, and in the examples provided below, some key numbers are collected in advance. These include:
- The number of concurrent Authoring users.
- The number of concurrent Reportal viewers.
- The number of launched surveys per year.
- Estimated maximum surveys (peak) launched over a period of one month.
- The number of expected completed responses collected per year.
- Estimated average survey pages per complete response ratio / average survey complexity. In the examples below, we have used an average ratio of 20 survey pages per completed response.
- Estimated response completion ratio (total page hits versus completes.) In the examples below, we have used an average completion ratio of 20% across all surveys.
- Estimated survey pages visitation peak over 24 hours (for instance if surveys are only visited by internal users within a company during work hours).
Example Scenario
A customer with 100 Authoring users expects to launch 2000 surveys over the course of a year. 500 of these will be launched in February, with an expectancy of 20 survey page hits per respondent to complete a survey. 1,000,000 completed responses are expected over the full year, with 150,000 of these expected in February, with 80% of the total page visits occurring during the working hours between 8am and 6pm, and 60% between 12pm and 4pm. The second year, a usage growth of 25% in response data collection is estimated. The following three years, 30% growth from the year before. Additionally, 25 new Authoring users will be hired each year.
From this, we can calculate that about 150,000 completed responses x 20 page hits will yield 3,000,000 page hits for the completes only. However, adding incompletes will result in 3,000,000 x (100/20) = 15,000,000 page hits in total in February alone. Spread out over 20 working days gives 750,000 page hits per day. 80% of these (600,000) hit the server in a ten-hour window, resulting in a total of 60,000 page hits on average, with 450,000 occurring over 4 hours – 112,500 page hits per hour in the peak period. The second year: ~140,000 page hits. The fifth year: 112,500*(1+25/100)*(1+30/100)*(1+30/100)*(1+30/100) resulting in ~310,000 page hits/hour peak. Additionally, there will be 225 Authoring users in the fifth year.
Based on this information, we can set up a site recommendation capable of handling the expected loads. In the first year, the mid-level scenario below should be sufficient, although by the fifth year, a layout somewhere between the mid-level and high-end setups would be recommended.
Entry-Level Multi-Server Setup
The minimum recommended configuration consists of a tri-server configuration, with dedicated database and deployment servers for data collection priority, and a combined Authoring/task system server for a small amount of project managers. In this scenario, the combined Authoring/task system server also runs the Metadata Rest API since this does not add noticeable strain to the server on which it runs with this amount of load.
Figure 1 - Features divided across three servers
The proposed configuration should be capable of handling approximately 40 concurrent Authoring users, and at least 120000 survey page hits per hour.
Mid-Level Multi-Server Setup
If service availability is starting to become a critical factor, one can start adding several servers into the same role to provide service redundancy, as shown in the example below. The proposed scenario would be recommended when data collection is of high importance, while temporary loss of Authoring services would be less critical.
Figure 2 - Multi-server setup with redundancy for data collection and response storage
The proposed configuration should be capable of handling approximately 75 concurrent Authoring users, and at least 250000 survey page hits per hour.
High-End Multi-Server Setup
When extreme performance and redundancy in all parts of the application is required, even more servers and network infrastructure can be added to the setup:
Figure 3 - Full redundancy for user-facing features
The proposed configuration should be capable of handling approximately 250 concurrent Authoring users, and at least 400000 survey page hits per hour. Larger environments can be suggested on request.