Single Server - Robust
Posit Connect can be configured to run on a single server, utilizing an external database and a networked file system. Use of these external components are optional for a single server implementation, but they present a more robust architecture in line with many organization’s best practices and existing processes. This architecture also offers flexibility to more easily scale Connect horizontally in the future without the complexity of migrating the database and application files.
Architectural overview
This implementation of Posit Connect includes the following components:
- A single AWS Elastic Compute Cloud (EC2) instance running Connect.
- AWS Relational Database Service (RDS) for PostgreSQL, serving as the application database for Connect.
- AWS Elastic File System (EFS), a networked file system used to store file data.
Architecture diagram
Nodes
This architecture utilizes a single EC2 instance running Posit Connect. During our performance tests, we used a t3.2xlarge
instance running Ubuntu 22.04.
Refer to the Posit Connect Admin Guide for detailed information on system requirements and installation steps.
Database
This architecture utilizes an RDS instance with PostgreSQL running on a db.m5.large
instance, provisioned with a minumum of 15 GB of storage and running the latest minor version of PostgreSQL 15 (see supported versions). Both the instance type and the storage can be scaled up for more demanding workloads.
- The RDS instance should be configured with an empty PostgreSQL database for the Connect metadata.
Storage
This architecture utilizes an encrypted AWS Elastic File System (EFS). EFS does not require initial sizing as it autoscales with usage.
Load balancer
This architecture utilizes an AWS Application Load Balancer (ALB) in order to provide public ingress to the Connect instances.
Networking
The architecture is implemented in a VPC, utilizing both public and private subnets. The RDS database instance, EFS mount targets, and the EC2 instances are located within the private subnets and ingress to the EC2 is managed through an ALB.
Configuration Details
The required configuration details are outlined in single server installation steps. Additionally, the following configuration should be performed:
Performance
The Connect team conducts performance testing on this architecture using the Grafana k6 tool. The workload consists of one virtual user (VU) publishing an R-based Plumber application repeatedly, while other VUs are making API fetch requests to a Python-based Flask application (using jumpstart examples included in the product).
The first test is a scalability test, where the number of VUs fetching the Flask app is increased steadily until the throughput is maximized. After noting the number of VUs needed to saturate the server, a second “load” test is run with that same number of VUs for 30 minutes, to accurately measure request latency when the server is fully utilized.
Below are the results for the load test:
- Average requests per second: 749 rps
- Average request latency (fetch): 294 ms
- Number of VUs: 250
- Error rate: 0%
(NOTE that k6 VUs are not equivalent to real-world users, as they were being run without sleeps, to maximize throughput. To approximate the number of real-world users, you could multiply the RPS by 10).
Please note that applications performing complex processing tasks will likely require nodes with larger amounts of CPU and RAM to perform that processing, in order to achieve the same throughput and latency results above. We suggest executing performance tests on your applications to accurately determine hardware requirements.
FAQ
See the Architecture FAQs page for the general FAQ.