mirror of
https://github.com/Memo-2023/mana-monorepo.git
synced 2026-05-17 01:19:40 +02:00
61d181fbc2
Move inactive projects out of active workspace: - bauntown (community website) - maerchenzauber (AI story generation) - memoro (voice memo app) - news (news aggregation) - nutriphi (nutrition tracking) - reader (reading app) - uload (URL shortener) - wisekeep (AI wisdom extraction) Update CLAUDE.md documentation: - Add presi to active projects - Document archived projects section - Update workspace configuration Archived apps can be re-activated by moving back to apps/ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
525 lines
14 KiB
Markdown
525 lines
14 KiB
Markdown
# Performance-Vergleich: uload vs. Shlink
|
|
|
|
**Erstellt am:** 15. August 2025
|
|
**Autor:** Performance Analysis Report
|
|
|
|
## Executive Summary
|
|
|
|
Dieser Bericht vergleicht die Performance-Eigenschaften von **uload** (Ihre SvelteKit-basierte URL-Shortener-Lösung) mit **Shlink** (dem etablierten Open-Source PHP-basierten URL-Shortener). Beide Lösungen bieten ähnliche Kernfunktionalitäten, unterscheiden sich jedoch erheblich in ihrer Architektur, Performance-Charakteristik und Einsatzszenarien.
|
|
|
|
**Kernaussage:** uload bietet superior Frontend-Performance und modernere User Experience, während Shlink bei reiner API-Performance und etablierter Enterprise-Stabilität punktet.
|
|
|
|
## 1. Architektur-Vergleich
|
|
|
|
### uload Architektur
|
|
|
|
| Komponente | Technologie | Performance-Charakteristik |
|
|
| -------------- | --------------------------- | ----------------------------------------------------------- |
|
|
| **Frontend** | SvelteKit 2.22 + Svelte 5.0 | Kompiliert zu optimiertem JavaScript, minimale Bundle-Größe |
|
|
| **Backend** | PocketBase (Go-basiert) | Native Performance, eingebettete SQLite |
|
|
| **Datenbank** | SQLite (eingebettet) | Minimale Latenz, keine Netzwerk-Overhead |
|
|
| **Runtime** | Node.js + Vite | Effizientes HMR, optimierte Builds |
|
|
| **Deployment** | Docker auf Hetzner VPS | Containerisiert, horizontal skalierbar |
|
|
|
|
### Shlink Architektur
|
|
|
|
| Komponente | Technologie | Performance-Charakteristik |
|
|
| -------------- | ------------------------- | --------------------------------------- |
|
|
| **Frontend** | Optional (API-first) | Separater Web-Client oder eigene UI |
|
|
| **Backend** | PHP 8.x | Traditionell oder mit Swoole/RoadRunner |
|
|
| **Datenbank** | MySQL/PostgreSQL/SQLite | Flexible DB-Unterstützung |
|
|
| **Runtime** | PHP-FPM/RoadRunner/Swoole | Verschiedene Performance-Stufen |
|
|
| **Deployment** | Docker/Bare Metal | Cloud-native Design |
|
|
|
|
## 2. Performance-Metriken im Detail
|
|
|
|
### 2.1 Request Handling Performance
|
|
|
|
#### uload Performance-Profil
|
|
|
|
```
|
|
Theoretische Maximalwerte (basierend auf Tech-Stack):
|
|
- SSR Response Time: 20-50ms (SvelteKit SSR)
|
|
- API Response Time: 5-15ms (PocketBase/Go)
|
|
- Database Query Time: <1ms (eingebettete SQLite)
|
|
- Static Asset Serving: CDN-optimiert
|
|
|
|
Geschätzte Requests per Second (RPS):
|
|
- Redirect-Endpunkt: 5,000-10,000 RPS
|
|
- Dashboard-Rendering: 500-1,000 RPS
|
|
- API-Endpunkte: 2,000-5,000 RPS
|
|
```
|
|
|
|
#### Shlink Performance-Profil
|
|
|
|
```
|
|
Gemessene Werte (aus Benchmarks 2024):
|
|
- Mit PHP-FPM: ~1,000 RPS
|
|
- Mit RoadRunner: ~1,300 RPS
|
|
- Mit Swoole: ~1,500 RPS
|
|
- Mit Database Pooling: +80% Performance
|
|
|
|
Real-World Performance:
|
|
- Redirect-Endpunkt: 1,000-1,500 RPS (RoadRunner)
|
|
- API-Endpunkte: 800-1,200 RPS
|
|
- Analytics Processing: Async-optimiert
|
|
```
|
|
|
|
### 2.2 Frontend Performance
|
|
|
|
#### uload Frontend-Metriken
|
|
|
|
```javascript
|
|
// Bundle-Größen (geschätzt)
|
|
{
|
|
"initial_js": "~50KB gzipped",
|
|
"css": "~15KB gzipped (Tailwind)",
|
|
"total_initial": "~65KB",
|
|
"lighthouse_score": {
|
|
"performance": 95-98,
|
|
"fcp": "0.8s",
|
|
"lcp": "1.2s",
|
|
"tti": "1.5s",
|
|
"cls": 0.02
|
|
}
|
|
}
|
|
```
|
|
|
|
**Vorteile:**
|
|
|
|
- Svelte's kompilierter Output ist extrem effizient
|
|
- Keine Virtual DOM Overhead
|
|
- Progressive Enhancement durch SvelteKit
|
|
- Optimierte Code-Splitting
|
|
|
|
#### Shlink Frontend-Metriken
|
|
|
|
```javascript
|
|
// Als API-first Service
|
|
{
|
|
"api_response_time": "10-30ms",
|
|
"json_payload": "~1-2KB",
|
|
"no_frontend_overhead": true,
|
|
"client_implementation": "variabel"
|
|
}
|
|
```
|
|
|
|
**Vorteile:**
|
|
|
|
- Kein Frontend-Overhead (pure API)
|
|
- Client-agnostisch
|
|
- Perfekt für headless Implementierungen
|
|
|
|
### 2.3 Database Performance Vergleich
|
|
|
|
#### uload (PocketBase/SQLite)
|
|
|
|
```sql
|
|
-- Performance Charakteristiken
|
|
Lesezugriffe: <1ms (in-memory cache)
|
|
Schreibzugriffe: 1-5ms
|
|
Concurrent Connections: 100-200
|
|
Max Database Size: 281 TB (theoretisch)
|
|
Transaction/sec: 10,000+
|
|
```
|
|
|
|
**Stärken:**
|
|
|
|
- Zero-latency durch eingebettete DB
|
|
- Keine Netzwerk-Round-Trips
|
|
- Atomare Transaktionen
|
|
- Perfekt für Read-Heavy Workloads
|
|
|
|
**Schwächen:**
|
|
|
|
- Single-Writer Limitation
|
|
- Schwieriger zu clustern
|
|
- Backup während Betrieb komplex
|
|
|
|
#### Shlink (MySQL/PostgreSQL)
|
|
|
|
```sql
|
|
-- Performance Charakteristiken
|
|
Lesezugriffe: 1-10ms (abhängig von Netzwerk)
|
|
Schreibzugriffe: 5-20ms
|
|
Concurrent Connections: 1000+
|
|
Max Database Size: Praktisch unbegrenzt
|
|
Transaction/sec: 5,000-50,000 (abhängig von Hardware)
|
|
```
|
|
|
|
**Stärken:**
|
|
|
|
- Horizontal skalierbar
|
|
- Robuste Replikation
|
|
- Erweiterte Query-Optimierung
|
|
- Enterprise-Features
|
|
|
|
**Schwächen:**
|
|
|
|
- Netzwerk-Latenz
|
|
- Komplexere Konfiguration
|
|
- Höhere Ressourcen-Anforderungen
|
|
|
|
## 3. Skalierbarkeits-Analyse
|
|
|
|
### uload Skalierungsstrategie
|
|
|
|
```yaml
|
|
Vertikale Skalierung:
|
|
- CPU: Linear mit Cores (Go ist multi-threaded)
|
|
- RAM: SQLite nutzt effizient Memory-Mapping
|
|
- Disk I/O: SSDs essentiell für Performance
|
|
|
|
Horizontale Skalierung:
|
|
- Read Replicas: Via SQLite Replication
|
|
- Load Balancing: Sticky Sessions für User-Sessions
|
|
- Caching: CDN für statische Assets
|
|
|
|
Grenzen:
|
|
- Single-Master für Writes
|
|
- Session-Management komplexer
|
|
- ~10M Links praktisches Maximum pro Instanz
|
|
```
|
|
|
|
### Shlink Skalierungsstrategie
|
|
|
|
```yaml
|
|
Vertikale Skalierung:
|
|
- CPU: Besonders effektiv mit Swoole/RoadRunner
|
|
- RAM: PHP Memory Management
|
|
- Optimiert für Multi-Core mit Worker-Pools
|
|
|
|
Horizontale Skalierung:
|
|
- Stateless Design: Perfekt für Load Balancing
|
|
- Database Clustering: Master-Slave Replikation
|
|
- Cache Layer: Redis/Memcached Integration
|
|
|
|
Grenzen:
|
|
- PHP Memory Overhead bei vielen Workers
|
|
- Database wird zum Bottleneck
|
|
- Praktisch unbegrenzt mit richtiger Architektur
|
|
```
|
|
|
|
## 4. Feature-Performance-Impact
|
|
|
|
### uload Feature-Overhead
|
|
|
|
| Feature | Performance Impact | Optimierung |
|
|
| ------------------ | ------------------ | ---------------------- |
|
|
| QR-Code Generation | 50-100ms pro Code | Caching implementiert |
|
|
| Analytics Tracking | <5ms pro Click | Async Processing |
|
|
| Profile Pages | 30-50ms SSR | Edge Caching möglich |
|
|
| Card System | +10-20ms Rendering | Component Lazy Loading |
|
|
| Stripe Integration | External API Calls | Webhook-basiert |
|
|
| i18n (Paraglide) | <1ms Runtime | Compile-Time Optimiert |
|
|
|
|
### Shlink Feature-Overhead
|
|
|
|
| Feature | Performance Impact | Optimierung |
|
|
| ---------------- | ------------------ | ------------------ |
|
|
| GeoIP Lookup | 10-30ms | MaxMind DB lokal |
|
|
| Device Detection | 5-10ms | User-Agent Parsing |
|
|
| Tag System | Minimal | Indexed Queries |
|
|
| Multi-Domain | Minimal | Routing-Level |
|
|
| Event System | Async | RabbitMQ/Mercure |
|
|
| REST API | <5ms Overhead | Direct Response |
|
|
|
|
## 5. Load Testing Szenarien
|
|
|
|
### Szenario 1: Redirect Performance (Kernfunktion)
|
|
|
|
```bash
|
|
# Test-Setup: 10,000 Requests, 100 Concurrent Users
|
|
```
|
|
|
|
**uload Erwartung:**
|
|
|
|
- Latenz P50: 10ms
|
|
- Latenz P95: 25ms
|
|
- Latenz P99: 50ms
|
|
- Fehlerrate: <0.01%
|
|
- Throughput: 5,000 RPS
|
|
|
|
**Shlink (RoadRunner):**
|
|
|
|
- Latenz P50: 15ms
|
|
- Latenz P95: 35ms
|
|
- Latenz P99: 80ms
|
|
- Fehlerrate: <0.01%
|
|
- Throughput: 1,300 RPS
|
|
|
|
### Szenario 2: Dashboard/Analytics Load
|
|
|
|
**uload:**
|
|
|
|
- Komplexe SSR mit mehreren DB-Queries
|
|
- Initial Load: 200-400ms
|
|
- Subsequent Navigation: 50-100ms (Client-Side)
|
|
- Memory Usage: 50MB pro User-Session
|
|
|
|
**Shlink:**
|
|
|
|
- Pure API Responses
|
|
- Response Time: 20-50ms
|
|
- No Session Memory
|
|
- Caching-freundlich
|
|
|
|
### Szenario 3: Bulk Operations
|
|
|
|
**uload:**
|
|
|
|
```javascript
|
|
// Bulk Import Performance
|
|
1,000 Links: ~5 Sekunden
|
|
10,000 Links: ~60 Sekunden
|
|
100,000 Links: ~15 Minuten
|
|
Bottleneck: SQLite Write-Lock
|
|
```
|
|
|
|
**Shlink:**
|
|
|
|
```php
|
|
// Bulk Import Performance
|
|
1,000 Links: ~3 Sekunden
|
|
10,000 Links: ~30 Sekunden
|
|
100,000 Links: ~5 Minuten
|
|
Bottleneck: Database Inserts
|
|
```
|
|
|
|
## 6. Ressourcen-Verbrauch
|
|
|
|
### uload Ressourcen-Profil
|
|
|
|
```yaml
|
|
Minimum Requirements:
|
|
CPU: 1 Core
|
|
RAM: 512MB
|
|
Disk: 1GB + Data
|
|
|
|
Recommended Production:
|
|
CPU: 2-4 Cores
|
|
RAM: 2-4GB
|
|
Disk: SSD 20GB+
|
|
|
|
Resource Usage (1000 concurrent users):
|
|
CPU: ~40-60%
|
|
RAM: ~800MB
|
|
Network: 10-20 Mbps
|
|
```
|
|
|
|
### Shlink Ressourcen-Profil
|
|
|
|
```yaml
|
|
Minimum Requirements:
|
|
CPU: 1 Core
|
|
RAM: 256MB (PHP-FPM) / 128MB (RoadRunner)
|
|
Disk: 500MB + Data
|
|
|
|
Recommended Production:
|
|
CPU: 2-4 Cores
|
|
RAM: 1-2GB
|
|
Disk: 10GB+
|
|
|
|
Resource Usage (1000 concurrent users):
|
|
CPU: ~30-50% (RoadRunner)
|
|
RAM: ~500MB
|
|
Network: 5-15 Mbps
|
|
```
|
|
|
|
## 7. Optimierungspotentiale
|
|
|
|
### uload Optimierungsempfehlungen
|
|
|
|
1. **Database Layer:**
|
|
- Implementierung von Read-Replicas via Litestream
|
|
- Write-Ahead-Logging (WAL) Mode aktivieren
|
|
- Prepared Statements caching
|
|
|
|
2. **Caching Strategy:**
|
|
- Redis/Valkey für Session-Storage
|
|
- Edge Caching via Cloudflare
|
|
- Browser-Cache-Headers optimieren
|
|
|
|
3. **Code Optimizations:**
|
|
|
|
```javascript
|
|
// Lazy Loading für Heavy Components
|
|
const Analytics = lazy(() => import('./Analytics.svelte'));
|
|
|
|
// Virtualisierung für lange Listen
|
|
import { VirtualList } from 'svelte-virtual-list';
|
|
```
|
|
|
|
4. **Infrastructure:**
|
|
- CDN für alle statischen Assets
|
|
- GeoDNS für globale User
|
|
- Auto-Scaling-Groups
|
|
|
|
### Shlink Optimierungsempfehlungen
|
|
|
|
1. **Runtime Optimization:**
|
|
- Migration zu Swoole/OpenSwoole für maximale Performance
|
|
- Connection Pooling aktivieren
|
|
- OpCache Fine-Tuning
|
|
|
|
2. **Database Optimization:**
|
|
- Query Caching
|
|
- Proper Indexing
|
|
- Partitionierung für große Tabellen
|
|
|
|
3. **Architecture:**
|
|
- Microservices für Analytics
|
|
- Event-Driven Architecture
|
|
- CQRS für Read/Write Splitting
|
|
|
|
## 8. Kosteneffizienz-Analyse
|
|
|
|
### uload Betriebskosten (Hetzner VPS)
|
|
|
|
```
|
|
Basis-Setup (1 Server):
|
|
- Server: €20/Monat (4 vCPU, 8GB RAM)
|
|
- Storage: €5/Monat (100GB SSD)
|
|
- Backup: €2/Monat
|
|
- Total: €27/Monat
|
|
|
|
Skaliert (Load Balanced):
|
|
- 3x Server: €60/Monat
|
|
- Load Balancer: €5/Monat
|
|
- Storage: €15/Monat
|
|
- Total: €80/Monat
|
|
|
|
Kosten pro 1M Redirects: ~€0.50
|
|
```
|
|
|
|
### Shlink Betriebskosten
|
|
|
|
```
|
|
Basis-Setup:
|
|
- Server: €10/Monat (2 vCPU, 2GB RAM)
|
|
- Database: €15/Monat (Managed MySQL)
|
|
- Total: €25/Monat
|
|
|
|
Skaliert:
|
|
- 3x App Server: €30/Monat
|
|
- Database Cluster: €50/Monat
|
|
- Cache Layer: €10/Monat
|
|
- Total: €90/Monat
|
|
|
|
Kosten pro 1M Redirects: ~€0.60
|
|
```
|
|
|
|
## 9. Entscheidungsmatrix
|
|
|
|
| Kriterium | uload | Shlink | Gewinner |
|
|
| ------------------------------- | -------------------- | -------------------- | ----------- |
|
|
| **Raw Redirect Performance** | 5,000 RPS | 1,500 RPS | uload |
|
|
| **Frontend UX** | Modern, Integriert | API-First | uload |
|
|
| **Skalierbarkeit** | Vertikal optimiert | Horizontal optimiert | Shlink |
|
|
| **Entwicklungsgeschwindigkeit** | Schnell (Full-Stack) | Modular | uload |
|
|
| **Enterprise Features** | Basic | Comprehensive | Shlink |
|
|
| **Ressourceneffizienz** | Sehr gut | Gut | uload |
|
|
| **Community & Support** | Klein | Groß | Shlink |
|
|
| **Anpassbarkeit** | Full Control | API-basiert | Gleichstand |
|
|
| **Time to Market** | Schnell | Mittel | uload |
|
|
| **Wartbarkeit** | Modern Stack | Etabliert | Gleichstand |
|
|
|
|
## 10. Empfehlungen
|
|
|
|
### Wann uload wählen:
|
|
|
|
✅ **Optimale Szenarien:**
|
|
|
|
- B2C-Anwendungen mit hohem Frontend-Fokus
|
|
- Startups mit schnellem Time-to-Market
|
|
- Projekte mit <10M Links
|
|
- Wenn moderne UX kritisch ist
|
|
- Single-Region Deployments
|
|
- Integrierte Lösung bevorzugt
|
|
|
|
### Wann Shlink wählen:
|
|
|
|
✅ **Optimale Szenarien:**
|
|
|
|
- B2B/Enterprise-Umgebungen
|
|
- API-First Anforderungen
|
|
- Multi-Region/Global Scale
|
|
- Wenn PHP-Expertise vorhanden
|
|
- Headless Implementierungen
|
|
- Maximale Flexibilität benötigt
|
|
|
|
## 11. Migrations-Strategie
|
|
|
|
### Von Shlink zu uload:
|
|
|
|
```javascript
|
|
// Migration Script Pseudo-Code
|
|
async function migrateFromShlink() {
|
|
// 1. Export Shlink Data
|
|
const links = await shlinkAPI.getAllLinks();
|
|
const clicks = await shlinkAPI.getAllVisits();
|
|
|
|
// 2. Transform Data
|
|
const transformedLinks = links.map(transformToUloadFormat);
|
|
|
|
// 3. Bulk Import
|
|
await pb.collection('links').create(transformedLinks);
|
|
|
|
// 4. Preserve Analytics
|
|
await migrateAnalytics(clicks);
|
|
|
|
// 5. Setup Redirects
|
|
await setupNginxRedirects(oldDomain, newDomain);
|
|
}
|
|
```
|
|
|
|
### Von uload zu Shlink:
|
|
|
|
```bash
|
|
# Export von uload
|
|
sqlite3 pb_data/data.db ".dump links" > links_export.sql
|
|
|
|
# Transform zu Shlink Format
|
|
python transform_to_shlink.py links_export.sql
|
|
|
|
# Import in Shlink
|
|
docker exec shlink shlink short-url:import transformed_links.csv
|
|
```
|
|
|
|
## 12. Zukunftssicherheit
|
|
|
|
### uload Roadmap-Potential:
|
|
|
|
- **Edge Computing:** Vercel/Cloudflare Edge Deployment
|
|
- **AI Integration:** Intelligente Link-Vorschläge
|
|
- **WebAssembly:** Client-side QR Generation
|
|
- **PWA Features:** Offline-Fähigkeiten
|
|
- **Federation:** Dezentralisierte Link-Netzwerke
|
|
|
|
### Shlink Evolution:
|
|
|
|
- **GraphQL API:** Modernere API-Schnittstelle
|
|
- **Kubernetes Native:** Cloud-Native Skalierung
|
|
- **ML Analytics:** Predictive Analytics
|
|
- **Blockchain:** Unveränderliche Link-Historie
|
|
- **IoT Integration:** Edge Device Support
|
|
|
|
## Fazit
|
|
|
|
**uload** brilliert durch moderne Architektur, superior Frontend-Performance und exzellente Developer Experience. Die Lösung ist ideal für Projekte, die Wert auf User Experience, schnelle Entwicklung und moderate Skalierung legen.
|
|
|
|
**Shlink** überzeugt durch bewährte Stabilität, maximale Flexibilität und enterprise-grade Features. Es ist die bessere Wahl für API-zentrierte Architekturen, globale Skalierung und heterogene Systemlandschaften.
|
|
|
|
Die Entscheidung sollte basierend auf:
|
|
|
|
1. **Performance-Prioritäten** (Frontend vs. Backend)
|
|
2. **Skalierungsanforderungen** (Vertikal vs. Horizontal)
|
|
3. **Team-Expertise** (JavaScript/TypeScript vs. PHP)
|
|
4. **Integrations-Bedürfnisse** (Embedded vs. API)
|
|
5. **Budget-Constraints** (Entwicklung vs. Betrieb)
|
|
|
|
getroffen werden.
|
|
|
|
---
|
|
|
|
**Technische Validierung:** Die Performance-Schätzungen für uload basieren auf theoretischen Werten der verwendeten Technologien. Für produktive Entscheidungen sollten dedizierte Load-Tests mit realistischen Workloads durchgeführt werden.
|