Axon API

I built an open-source WSGI core that consumes dynamic batch requests via query strings and bundles the specified files into a multipart stream. Axon is synchronous and implemented in 507 lines of Python with zero dependencies. I designed it for the rapid prototyping of experimental applications that require granular control over the request lifecycle. I needed something simple enough to retool quickly but performant enough to scale.

You can validate these capabilities with the included deployment tools. Get a live demo running in under 5 minutes with the Ubuntu deployment script, then start stress testing with the included client script. The tests reveal Axon's architectural characteristics: on single-core hardware, CPU saturation occurs before network limits; multicore deployments may shift bottlenecks to network throughput depending on processing power and bandwidth constraints. Since performance scales with computational resources rather than I/O, the architecture supports distributed strategies that specialize nodes by file type and size.

Multipart Streaming Axon returns multiple files through a single HTTP connection using a Python generator to dispense data with multipart boundaries via stream. This approach maintains constant memory usage while CPU utilization scales with request volume and payload size. 64KB chunks optimize throughput for mixed file sizes. System memory remained under 225MB while CPU utilization was maxed throughout all test scenarios.

Backpressure Handling The iterator works like a revolver - each chunk is 'chambered' on request. The iterator is called by WSGI on client demand, preventing memory buildup. This demand-driven mechanism explains why 16 threads proved optimal - threads only activate when releasing data. Thread count likely scales with network latency to better manage concurrent I/O waits, while processes scale with CPU cores.

Performance testing was conducted using identical Digital Ocean droplets ($8/month, 1GB RAM, 1 Intel CPU, 35GB NVMe SSD) deployed in the NYC3 datacenter to minimize network latency between Axon and the stress testing client. Axon used 2 processes and 16 threads per process based on 25 preliminary optimization tests that determined this configuration was optimal for the hardware, with 2 processes providing a slight advantage over 1 process while improving error recovery. Chunk size was set to 64KB across Axon, uWSGI, and nginx layers after testing 8KB-64KB chunks.

Each test iteration involved deploying a fresh Axon instance via script, transferring test files with SCP, and executing wrk with 50 concurrent connections for a 1-minute warmup period followed by 10 minutes of sustained testing. Eight test scenarios were designed as four payload-size pairs (8KB, 64KB, 256KB, 512KB) with each pair testing single-file versus multi-file handling to isolate file processing overhead from payload size effects. The testing droplet was destroyed after each iteration to ensure consistent baseline conditions.

Process

1. I deployed a new droplet
2. I ran deploy-axon.sh with:
   chmod +x deploy-axon.sh && ./deploy-axon.sh
3. I sent the required test file to the server with:
   scp ./[FILE_NAME].[EXTENSION] root@[DROPLET_IP]:/var/www/axon-api/examples/
4. I checked the endpoint with:
   curl http://[DROPLET_IP]/api/health
5. I ran the 1-minute burst test with:
   wrk -t10 -c50 -d60s --latency "http://[DROPLET_IP]/api/stream-files?file1=examples/[FILE_NAME].[EXTENSION]&file2=examples/[FILE_NAME].[EXTENSION]"
6. I ran the 10-minute sustained test with:
   wrk -t10 -c50 -d600s --latency "http://[DROPLET_IP]/api/stream-files?file1=examples/[FILE_NAME].[EXTENSION]&file2=examples/[FILE_NAME].[EXTENSION]"
7. I recorded my results and destroyed the droplet

Axon fully utilizes CPU while maintaining constant memory usage. Computational overhead from multipart boundary generation and header construction constrains throughput rates. Generator-based streaming maintains bounded memory under load achieving zero socket errors across all test scenarios.

Baseline tests measured the framework's maximum throughput (on this hardware) using two scenarios: a health endpoint returning JSON and invalid file requests triggering error responses.