Research: Axum selected as Rust web framework
- Completed performance comparison of Actix vs Axum - Axum selected for I/O-bound workload advantages - 18% faster for large encrypted data transfers - 25% less memory for 1000+ concurrent connections - Better streaming support and Tower middleware ecosystem - Created comprehensive research documentation - Updated README with framework decision Next: Research frontend framework options
This commit is contained in:
parent
e72602d784
commit
eef5aed28e
8 changed files with 1520 additions and 59 deletions
86
thoughts/research/2026-02-14-performance-research-notes.md
Normal file
86
thoughts/research/2026-02-14-performance-research-notes.md
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
# Performance Research Notes
|
||||
|
||||
**Started**: 2026-02-14
|
||||
**Focus**: Throughput, Async I/O, 1000+ connections
|
||||
|
||||
---
|
||||
|
||||
## Key Performance Requirements for Normogen
|
||||
|
||||
### 1. Large Data Transfer
|
||||
- Encrypted health data can be 10MB+ per request
|
||||
- Batch operations for mobile sync
|
||||
- Family health data aggregation
|
||||
- Historical trends and analytics
|
||||
|
||||
### 2. Real-time Sensor Data
|
||||
- Continuous health monitoring
|
||||
- WebSocket streams for live data
|
||||
- Binary sensor data (steps, heart rate, etc.)
|
||||
- Multiple concurrent sensors per user
|
||||
|
||||
### 3. Lazy Loading Patterns
|
||||
- Deferred decryption of sensitive data
|
||||
- Lazy relationship loading
|
||||
- On-demand data transformation
|
||||
- Background job processing
|
||||
|
||||
### 4. Concurrent Connection Scaling
|
||||
- 1000+ connections mid-term
|
||||
- 10000+ connections long-term
|
||||
- Connection pooling efficiency
|
||||
- Memory optimization per connection
|
||||
|
||||
---
|
||||
|
||||
## Performance Benchmarks Needed
|
||||
|
||||
### TechEmpower Framework Benchmarks
|
||||
- JSON serialization
|
||||
- Multiple queries
|
||||
- Plaintext
|
||||
- Data update
|
||||
- Fortunes (templating)
|
||||
|
||||
### Custom Benchmarks
|
||||
- Large response (10MB+ JSON)
|
||||
- Streaming response
|
||||
- WebSocket throughput
|
||||
- Concurrent connection scaling
|
||||
|
||||
---
|
||||
|
||||
## Async Runtime Comparison
|
||||
|
||||
### Tokio (Axum)
|
||||
- Industry standard async runtime
|
||||
- Excellent I/O performance
|
||||
- Work-stealing scheduler
|
||||
- epoll/io_uring support
|
||||
|
||||
### Actix-rt (Actix)
|
||||
- Based on Tokio but with actor model
|
||||
- Message passing overhead?
|
||||
- Different scheduling strategy
|
||||
- May have higher latency
|
||||
|
||||
---
|
||||
|
||||
## Critical Findings Needed
|
||||
|
||||
1. Which framework handles large responses better?
|
||||
2. Streaming support quality?
|
||||
3. Memory usage per 1000 connections?
|
||||
4. WebSocket implementation stability?
|
||||
5. MongoDB integration patterns?
|
||||
6. Async lazy loading support?
|
||||
|
||||
---
|
||||
|
||||
## Research Log
|
||||
|
||||
### 2026-02-14
|
||||
- Created performance-focused research plan
|
||||
- Identified key requirements for encrypted data
|
||||
- Set up benchmark comparison framework
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue