Back to .md Directory

Pasto Performance Benchmarks

Provides a template for benchmarking Pasto's HTTP performance across multiple machines and worker counts.

May 2, 2026
0 downloads
1 views
ai
View source

What this file does

Provides a template for benchmarking Pasto's HTTP performance across multiple machines and worker counts.

When to use it

  • You need to measure throughput and latency of a Crystal web app
  • You want to compare performance across different hardware configurations
  • You plan to scale workers and need data on diminishing returns
  • You are writing a performance section for your project's documentation

Assumes this stack

Crystalwrk

Pasto Performance Benchmarks

This document contains performance benchmarks for Pasto across different hardware configurations.

Test Environment

Machine 1: [Machine Name]

  • CPU: [CPU model and cores]
  • Memory: [Total RAM]
  • OS: [Operating system and version]
  • Crystal Version: [version]
  • Build: [debug/release, any special flags]
  • Date: [Test date]

Machine 2: [Machine Name]

  • CPU: [CPU model and cores]
  • Memory: [Total RAM]
  • OS: [Operating system and version]
  • Crystal Version: [version]
  • Build: [debug/release, any special flags]
  • Date: [Test date]

Machine 3: [Machine Name]

  • CPU: [CPU model and cores]
  • Memory: [Total RAM]
  • OS: [Operating system and version]
  • Crystal Version: [version]
  • Build: [debug/release, any special flags]
  • Date: [Test date]

Benchmark Methodology

Tool

  • wrk - HTTP benchmarking tool
  • Configuration: 4 threads, 100 concurrent connections, 30 second duration
  • Warmup: 5 seconds before each test

Workloads

1. View Paste (Read)

  • Endpoint: GET /:id
  • Description: View an existing paste
  • Cache: Cached for anonymous users (1 hour TTL)
  • Content: Medium-sized code paste

2. List Pastes (Read)

  • Endpoint: GET /
  • Description: Homepage with paste listing
  • Cache: Not cached (dynamic content)

3. Root Page (Light)

  • Endpoint: GET /
  • Description: Minimal page load
  • Cache: Not cached

4. Create Paste (Write)

  • Endpoint: POST /create
  • Description: Create a new paste
  • Cache: Not applicable (write operation)
  • Content: Small text paste

Results

Machine 1: [Name]

1 Worker Instance

TestRPSAvg LatencyStdevP50P99
View Paste-----
List Pastes-----
Root Page-----
Create Paste-----

2 Worker Instances

TestRPSAvg LatencyStdevP50P99
View Paste-----
List Pastes-----
Root Page-----
Create Paste-----

4 Worker Instances

TestRPSAvg LatencyStdevP50P99
View Paste-----
List Pastes-----
Root Page-----
Create Paste-----

8 Worker Instances

TestRPSAvg LatencyStdevP50P99
View Paste-----
List Pastes-----
Root Page-----
Create Paste-----

12 Worker Instances

TestRPSAvg LatencyStdevP50P99
View Paste-----
List Pastes-----
Root Page-----
Create Paste-----

Machine 2: [Name]

[Repeat same structure as Machine 1]

Machine 3: [Name]

[Repeat same structure as Machine 1]

Analysis

Scaling Characteristics

Horizontal Scaling (Multiple Workers)

  • [Analysis of how performance scales with additional workers]
  • [Optimal worker count for each machine]
  • [Diminishing returns point]

Performance Per Core

  • [RPS per CPU core for each configuration]
  • [Most efficient configuration]

Workload Analysis

Read Performance

  • [View paste performance across machines]
  • [Impact of caching]
  • [Best performance achieved]

Write Performance

  • [Create paste performance]
  • [Bottleneck identification]
  • [Comparison with read performance]

Cross-Machine Comparison

CPU Performance

  • [Comparison of single-instance performance]
  • [Scaling efficiency comparison]
  • [Price-performance ratio (if applicable)]

Memory Usage

  • [Memory consumption per instance]
  • [Total memory usage at optimal configuration]

Conclusions

Key Findings

  1. [Main finding 1]
  2. [Main finding 2]
  3. [Main finding 3]

Recommendations

For Deployment

  • Small VPS (1-2 cores): Use [X] workers
  • Medium VPS (4 cores): Use [X] workers
  • Large Server (8+ cores): Use [X] workers

For Development

  • [Development environment recommendations]

Future Optimizations

  • [Areas identified for potential improvement]
  • [Caching strategies]
  • [Code optimization opportunities]

Appendix: Raw Data

Full benchmark results are available in the benchmark_results-* directories:

Each directory contains:

  • system-info.txt: Detailed system information
  • summary.txt: Human-readable summary
  • view-*.txt, list-*.txt, create-*.txt: Raw wrk output

Running the Benchmarks

To reproduce these benchmarks:

# Install wrk
# Ubuntu/Debian: sudo apt install wrk
# macOS: brew install wrk
# Or build from source: https://github.com/wg/wrk

# Build Pasto in release mode (recommended for accurate results)
shards build --release pasto

# Run the benchmark script
./benchmark.sh

# Results will be saved to benchmark_results-[timestamp]/

Environment Variables

  • PASTO_BIN: Path to Pasto binary (default: ./bin/pasto)
  • BASE_PORT: Starting port number (default: 4000)
  • DURATION: Test duration (default: 30s)
  • WRK_THREADS: Number of wrk threads (default: 4)
  • WRK_CONNECTIONS: Number of concurrent connections (default: 100)
  • TEST_PASTE_ID: ID of paste to use for view tests (default: ca447b58...)

Example

# Run with custom settings
DURATION=60s WRK_CONNECTIONS=200 ./benchmark.sh

# Test a specific binary
PASTO_BIN=/path/to/pasto ./benchmark.sh

Last updated: [Date] Crystal version: [Version] Pasto version: [Version]

What's inside

5 sections: test environment, methodology, results tables, analysis, appendix with raw data and reproduction steps

Change this for your project

  • Replace Pasto references with your project name
  • Replace ca447b58... with a real paste ID for view tests
  • Replace benchmark.sh with your own benchmark script path
  • Replace machine names and hardware specs with your test machines

Where it goes

Keep it in your repository where the agent or team that needs it will read it.

Worth borrowing

  • Structuring benchmarks by workload type (read, write, cached, uncached)
  • Testing multiple worker counts to find scaling limits
  • Providing a reproduction script with environment variables for customisation

Related Documents