While the topic comes up periodically, designing a one-size-fits-all Exago system is very difficult—arguably impossible. Like any new system, providing specific hardware, network, and software specifications for a generalized "requirement" will, at best, provide mediocre results.

While Exago can certainly run on a low-specification laptop, in a production environment, a quad-core VM with 32GB RAM on a gigabit network running Windows 10 or Linux should support dozens of simultaneous users running average-sized reports. From this most generic specification, there are a number of considerations that should be reviewed in order to strategically expand hardware specifications according to any additional known input. It's also recommended that a certain amount of system growth is calculated into the final specification.

Lastly, as an addendum to this document, actual specifications provided to Exago from current clients running on the AWS platform are available. Given the generic specification above, the considerations below, and the examples, an accurate depiction of hardware, network, and software requirements, specific to your organization, should be attainable.

Assumptions

Rather than starting with considerations immediately, here are a number of base assumptions that will help focus the initiative, reiterating some of the aforementioned points.

• A quad-core VM with 32GB RAM is a base configuration.
• Gigabit network (or better) wherever possible.
• All server clusters (web application, state, scheduler, database(s), etc) should be located within close geographical "zones". If multiple geographical zones need to be supported to address the full user base, consider mirroring server clusters in multiple zones, managing zone traffic using load balancing technology to distribute traffic based on locale.
• Use persistent (not transient) local storage such that optional log and monitoring data is retained across potential server bounces.
• The database and/or database server will NOT be taken into consideration here. It's assumed that the database/database server can handle any additional load Exago may put on it appropriately and without being a bottleneck.
• Aside from the possibility that Exago runs on the same server as the host software within which it is embedded, as in the case of a full .NET implementation, it's assumed that there are no other systems running on this server, vying for resources.
• Windows and the IIS web application server arguably requires more CPU/RAM than Linux equivalents (including mono), if only slightly. That said, for these purposes, an attempt will be made to consider the OS and web application server generically.

Web Application Server

There are a number of considerations pertaining to sizing the main server that runs Exago's core software.

• REST API vs. .NET API (with or without JavaScript API): Within Exago, API choice is largely irrelevant. In isolation, there is negligible latency associated with the REST API due to it simply serving as an interface to the .NET API behind the scenes. The real difference, however, between the two would be associated latency due to network packaging and traffic intrinsic to REST as compared to the .NET API "communicating" in machine memory. This can be mitigated somewhat by using Exago's batch REST interface. Of course, while a .NET API solution would likely have the host application on the same web application server, requiring the server to be sized accordingly, using the REST API affords greater load distribution across servers.
• Web application servers can typically handle >10k "requests" per second. Each Exago user hit, however, typically includes up to hundreds of "requests," including images, styling, code executions, and so on. This is why a given web application server typically handles up to dozens of Exago users simultaneously. The more simultaneous users expected to be supported by a given server, the more RAM will be necessary to do so. Once the server approaches maximum RAM configuration, it's better to build a server farm of web application servers horizontally to host a growing user base. This is especially true for a user base distributed across wide geographical zones, as described above. A multi-server web farm also affords a level of redundancy should a server failure ensue.
  • Configuring multiple web application servers as a farm requires (at least) the following:
    • A load balancer. In the case of managing geographical zones, a load balancer would serve as a router as well, ensuring that user traffic is routed towards server clusters that are geographically "near" the user.
    • A state server. The state server ensures that client (browser)/server (Exago) "conversations" are retained by consistent machines throughout the conversation in order to ensure that session data is retained.

Scheduler Service

The Scheduler Service allows for the offloading and distribution of report execution to zero or more separate hardware servers for both load balancing and execution isolation. For maximum benefit, it should be installed on separate servers in order to isolate immediate and/or remote executions or scheduled executions across multiple machines as appropriate.

• A Scheduler Queue (software) should be considered in a production environment. While the Scheduler Queue can typically live on the Exago Web Application Server with little to no additional hardware considerations, answers to the following questions may or may not necessitate more hardware-intensive servers.
  • Is there a heavier than average reliance on schedulers and scheduled report execution?
  • Does the implementation require a database for scheduled job storage?
• A Scheduler Service configured as a stand-alone server could be less hardware-intensive than a full web application server installation of Exago since, by itself, it is lighter-weight server software and does not need to support web application server software.
• If the web application server, sans a scheduler server being configured, is becoming taxed or if a significant load simply from the number of users a web application server needs to support is expected, one or more scheduler servers can be installed in order to offload report execution load to a separate VM, thus reducing or eliminating the report execution "responsibility" of the web application server itself.

• If there are a significant number of scheduled reports, long-running reports, or reports running concurrently, one or more scheduler servers can be installed on separate servers in order to offload report execution, again, reducing or eliminating the report execution "responsibility" of the web application server itself. Load will be distributed by Exago’s core engine based on available resources (CPU and RAM primarily).

• If there is a specific time window within which report execution must complete, separate scheduler servers will help ensure that these execution windows are adhered to.
• Report execution servers and scheduler servers, both achieved using the scheduler server software but configured separately in Exago's Administration Console, should not be configured to be on the same installed scheduler server. Remote execution will take priority over scheduled executions, if on the same server, potentially delaying scheduled jobs and pushing the execution window.

• Remote execution servers
• Intended for less time-consuming reports than scheduled reports since user is waiting for report execution to complete.
• Under normal circumstances, these servers can be less hardware intensive than scheduler servers, based on the assumption that these should be smaller, faster reports in the first place.
• If larger reports expected to be executed via remote execution, however, aforementioned bullets are null and void, and more capable hardware should be specified.
• Scheduled execution servers
• Expected to be long-running reports and would likely require hardware based on the window within which reports need to be completed. Smaller window would require more hardware-intensive servers. 
• The time window would likely be defined in conjunction with database server, etc availability requirements.

CPU- and RAM-Optimization

Whether report execution is isolated to scheduler servers or continues to be done on the web application server itself, the reports themselves may help further dictate hardware specifications. Some data centers, and certainly many IaaS and PaaS vendors, offer optimized hardware and auto-scaling options that can be taken advantage of when considering hardware specifications. While the added cost for optimized hardware may not be justifiable for less-than-average use of some Exago features, it would certainly be justified if typically exercising the many powerful features that Exago offers out of the box.

• CPU-Optimized server: the following Exago features may benefit from a CPU-centric hardware design.
• Are reports heavily formatted, include significant cross-platform joining, conditional logic, custom fields, or formulas?
• Dashboard component will, optimally, run in its own thread/core. Therefore, if dashboard executions are common, increased CPU cores would be beneficial. 
• Are extensive cross-tab reports commonly executed?
• RAM-Optimized server: the following reporting scenarios may benefit from a RAM-centric hardware design.
• Are your reports longer or wider than average? The more data that needs to be brought into the system from the database, the more RAM would be needed to avoid thrashing from short term to long term storage in order to complete report execution.
• Do you have extensive cross-tab reports? Cross-tab reports are data-intensive so the previous bullet applies.
• Do you have default filters, optional filters, or the ability for users to inadvertently execute reports on massive data sets? While there are many controls available to prevent massive, accidental report executions, it’s entirely possible that large reports are needed. Again, the first bullet applies here.
• Auto-scaling: some vendors have the ability to combine monitoring features with auto-scaling to ramp up hardware specifications should the load require. While there is cost associated with auto-scaling, it allows the system to meet the needs of an inconsistent load with minimal idle hardware.

Extensibility

• Extensibility (Server Events/Action Events/Scheduler Queue) will all be loaded and executed on the same server as the Exago web application. Assuming a configurable file system connection between the Exago Web Application and Extensibility implementation, Extensibility code can be stored on a separate server. It still will execute on the same server as the Exago core code.
• Folder Management also executes as part of the Exago Web Application; however, it typically interfaces with external components (database, web services, etc.).
• Extensibility code may necessitate a stronger Exago Web Application server and/or networking in the following scenarios:
• Extensibility code performs long-running tasks. Generally, Extensibility hooks are blocking calls and would need to return in a timely fashion, so the idea of long-running Extensibility should be avoided whenever possible.
• Extensibility code requires hardware-intensive operations (for example, significant mathematical computation).
• Extensibility code requires extensive database queries or data manipulation outside of what is done within Exago.

Client’s Installations

Two clients offered their hardware specifications as currently installed on AWS. Approximate users supported and associated costs are provided. (Prices as of August 2018.)

• Client 1:

• 4 x m4.xLarge EC2 instance farm (4 x $0.20/hr = $576/mo) for web application and report execution
• Elastic Load Balancing w/ sticky sessions ($0.0225/hr = $16.20; additional cost for average traffic rates at $0.008/LCU-hour)
• Exago Scheduler(s) run on aforementioned EC2 instances
• CPU Utilization averages < 20%
• No auto-scaling configured at this time
• Approximately 24,000 users/mo
• Approximate cost < $600/mo

• Client 2:

• 1 x c3.4xLarge EC2 instance ($0.84/hr = $604.80/mo) for web application and report execution
• 1 x c3.8xLarge EC2 instance ($1.68/hr = $1,209.60/mo) for dashboard execution
• 2 x c3.xLarge EC2 instance (2 x $0.21/hr = $302.40/mo) for Exago Schedulers/scheduled report execution and back-up on-demand report execution
• No auto-scaling configured
• Approximately 10,000 users/day (45,000 users in the system)
• Approximate costs < $2200/mo