Single Server

Posit Connect can be configured to run on a single server, without requiring any additional storage resources. The content data bundles are stored on the server, and the content processes run on the same server. This architecture is designed to provide a simple, cost-effective way to run Connect for small teams or organizations.

Architectural overview

This implementation of Posit Connect includes the following components:

Because a standalone instance of Connect includes both the published application data and the internal Connect SQLite database, we recommend following your organization’s backup and retention strategies to maintain snapshots of the EBS volume associated with this EC2 instance.

Architecture diagram

Architecture Diagram

Architecture Diagram

Nodes

This architecture utilizes a single EC2 instance running Posit Connect. During our performance tests, we used a m6i.2xlarge instance running Ubuntu 22.04.

Refer to the Posit Connect Admin Guide for detailed information on system requirements and installation steps.

Database

SQLite is the default database provider for Posit Connect and does not require any additional setup. You can find more information about SQLite in the Admin Guide.

Storage

This architecture will store application data on the local EBS storage provisioned for the EC2 instance.

Networking

The architecture is implemented in a virtual private cloud, utilizing only public subnets. Ingress to the EC2 should be restricted thought the use of Security Groups.

Configuration details

No additional configuration is required for this architecture beyond the initial setup steps outlined in the local single server installation steps.

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: 1287 rps
  • Average request latency (fetch): 178 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.