Für den Launch im September, würde ich gerne noch eine 2.Instanz aufsetzen ich hätte aktuell noch einen 2. server im gleichen netzwerk.
hierführ wäre aber noch ein loadbalancer nötig.
oder siehst du hier kein bedarf, bei mehr als 300-400 anfragen (geschätzt)
Für den Launch im September, würde ich gerne noch eine 2.Instanz aufsetzen ich hätte aktuell noch einen 2. server im gleichen netzwerk.
hierführ wäre aber noch ein loadbalancer nötig.
oder siehst du hier kein bedarf, bei mehr als 300-400 anfragen (geschätzt)
admin
added the due date 2026-08-312026-08-15 22:07:15 +02:00
Update nach Lasttest (2026-08-15): App-CPU ist der Engpass, kein Cloudflare/Proxy-Problem — Empfehlung geändert
Habe gegen die Live-Seite (noch keine aktiven Nutzer, daher risikofrei) mit autocannon getestet:
Verbindungen
Req/Sek. (Median)
Latenz (Median)
Latenz (Max)
10
57
187 ms
498 ms
50
62
802 ms
1064 ms
100
64
1581 ms
2220 ms
Harte Durchsatz-Decke bei ~60–65 Req/Sek. (~216k/h, weit über den 300–400 aus der Ausgangsfrage) — keine Fehler, aber Latenz steigt linear mit der Last, statt dass mehr durchkommt.
Ursache bestätigt: CPU-Last während des Tests lag bei 133% (Daniel, live beobachtet). Die NAS hat 4 Kerne (i5-6500 @ 3.6GHz) — 133% heißt: ein einzelner Kern wird nahezu voll ausgeschöpft, die anderen 3 liegen brach. Grund: docker/Dockerfile:78 startet die App als einzelnen node server.js-Prozess — Next.js Standalone-Output ist von Haus aus single-process.
Das ändert meine ursprüngliche Einschätzung: Ihr braucht wahrscheinlich keinen zweiten physischen Server + externen Loadbalancer — die Maschine hat noch 3 ungenutzte Kerne. Besserer erster Schritt: 2–3 PawFeed-Container-Replicas auf derselben NAS (gleiche DB/Redis), load-balanced über den bereits vorhandenen Nginx Proxy Manager. Kein neuer Server nötig, deutlich günstiger und schneller umsetzbar. Ein zweiter Server macht erst Sinn, wenn die Gesamt-CPU der Maschine an ihre Grenze kommt (aktuell noch nicht der Fall) oder wenn echte Hardware-Redundanz gegen NAS-Totalausfall gewünscht ist.
Detaillierte Umsetzungs-Roadmap für die Container-Replicas + NPM-Anpassung liegt unter docker/SCALING-ROADMAP.md im Repo.
**Update nach Lasttest (2026-08-15): App-CPU ist der Engpass, kein Cloudflare/Proxy-Problem — Empfehlung geändert**
Habe gegen die Live-Seite (noch keine aktiven Nutzer, daher risikofrei) mit `autocannon` getestet:
| Verbindungen | Req/Sek. (Median) | Latenz (Median) | Latenz (Max) |
|---|---|---|---|
| 10 | 57 | 187 ms | 498 ms |
| 50 | 62 | 802 ms | 1064 ms |
| 100 | 64 | 1581 ms | 2220 ms |
Harte Durchsatz-Decke bei ~60–65 Req/Sek. (~216k/h, weit über den 300–400 aus der Ausgangsfrage) — keine Fehler, aber Latenz steigt linear mit der Last, statt dass mehr durchkommt.
**Ursache bestätigt:** CPU-Last während des Tests lag bei 133% (Daniel, live beobachtet). Die NAS hat 4 Kerne (i5-6500 @ 3.6GHz) — 133% heißt: ein einzelner Kern wird nahezu voll ausgeschöpft, die anderen 3 liegen brach. Grund: `docker/Dockerfile:78` startet die App als einzelnen `node server.js`-Prozess — Next.js Standalone-Output ist von Haus aus single-process.
**Das ändert meine ursprüngliche Einschätzung:** Ihr braucht wahrscheinlich **keinen zweiten physischen Server + externen Loadbalancer** — die Maschine hat noch 3 ungenutzte Kerne. Besserer erster Schritt: 2–3 PawFeed-Container-Replicas auf derselben NAS (gleiche DB/Redis), load-balanced über den bereits vorhandenen Nginx Proxy Manager. Kein neuer Server nötig, deutlich günstiger und schneller umsetzbar. Ein zweiter Server macht erst Sinn, wenn die Gesamt-CPU der Maschine an ihre Grenze kommt (aktuell noch nicht der Fall) oder wenn echte Hardware-Redundanz gegen NAS-Totalausfall gewünscht ist.
Detaillierte Umsetzungs-Roadmap für die Container-Replicas + NPM-Anpassung liegt unter `docker/SCALING-ROADMAP.md` im Repo.
Umgesetzt und live (2026-08-16).pawfeed-1/2/3 laufen als 3 Replicas hinter NPM (least_conn-Upstream in /data/nginx/custom/http_top.conf, Proxy-Host-Override auf pawfeed_upstream). Cutover ohne Downtime (temporärer Netzwerk-Alias während der Umstellung, danach entfernt). Verifiziert per Lasttest (autocannon -c 30 -d 10): CPU verteilt sich jetzt gleichmäßig auf allen 3 Replicas (~100% je Container) statt vorher 133% auf einem Kern. Prisma-Pool per Replica auf DB_POOL_MAX=10 gecappt (3 x 10 = 30, weit unter dem Supabase-Limit von 200 Max Client Connections).
Voller Runbook-Stand in docker/SCALING-ROADMAP.md im Repo, auch in CLAUDE.md/README.md vermerkt. Zweiter physischer Server weiterhin nicht nötig.
**Umgesetzt und live (2026-08-16).** `pawfeed-1/2/3` laufen als 3 Replicas hinter NPM (`least_conn`-Upstream in `/data/nginx/custom/http_top.conf`, Proxy-Host-Override auf `pawfeed_upstream`). Cutover ohne Downtime (temporärer Netzwerk-Alias während der Umstellung, danach entfernt). Verifiziert per Lasttest (`autocannon -c 30 -d 10`): CPU verteilt sich jetzt gleichmäßig auf allen 3 Replicas (~100% je Container) statt vorher 133% auf einem Kern. Prisma-Pool per Replica auf `DB_POOL_MAX=10` gecappt (3 x 10 = 30, weit unter dem Supabase-Limit von 200 Max Client Connections).
Voller Runbook-Stand in `docker/SCALING-ROADMAP.md` im Repo, auch in `CLAUDE.md`/`README.md` vermerkt. Zweiter physischer Server weiterhin nicht nötig.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Für den Launch im September, würde ich gerne noch eine 2.Instanz aufsetzen ich hätte aktuell noch einen 2. server im gleichen netzwerk.
hierführ wäre aber noch ein loadbalancer nötig.
oder siehst du hier kein bedarf, bei mehr als 300-400 anfragen (geschätzt)
Update nach Lasttest (2026-08-15): App-CPU ist der Engpass, kein Cloudflare/Proxy-Problem — Empfehlung geändert
Habe gegen die Live-Seite (noch keine aktiven Nutzer, daher risikofrei) mit
autocannongetestet:Harte Durchsatz-Decke bei ~60–65 Req/Sek. (~216k/h, weit über den 300–400 aus der Ausgangsfrage) — keine Fehler, aber Latenz steigt linear mit der Last, statt dass mehr durchkommt.
Ursache bestätigt: CPU-Last während des Tests lag bei 133% (Daniel, live beobachtet). Die NAS hat 4 Kerne (i5-6500 @ 3.6GHz) — 133% heißt: ein einzelner Kern wird nahezu voll ausgeschöpft, die anderen 3 liegen brach. Grund:
docker/Dockerfile:78startet die App als einzelnennode server.js-Prozess — Next.js Standalone-Output ist von Haus aus single-process.Das ändert meine ursprüngliche Einschätzung: Ihr braucht wahrscheinlich keinen zweiten physischen Server + externen Loadbalancer — die Maschine hat noch 3 ungenutzte Kerne. Besserer erster Schritt: 2–3 PawFeed-Container-Replicas auf derselben NAS (gleiche DB/Redis), load-balanced über den bereits vorhandenen Nginx Proxy Manager. Kein neuer Server nötig, deutlich günstiger und schneller umsetzbar. Ein zweiter Server macht erst Sinn, wenn die Gesamt-CPU der Maschine an ihre Grenze kommt (aktuell noch nicht der Fall) oder wenn echte Hardware-Redundanz gegen NAS-Totalausfall gewünscht ist.
Detaillierte Umsetzungs-Roadmap für die Container-Replicas + NPM-Anpassung liegt unter
docker/SCALING-ROADMAP.mdim Repo.Umgesetzt und live (2026-08-16).
pawfeed-1/2/3laufen als 3 Replicas hinter NPM (least_conn-Upstream in/data/nginx/custom/http_top.conf, Proxy-Host-Override aufpawfeed_upstream). Cutover ohne Downtime (temporärer Netzwerk-Alias während der Umstellung, danach entfernt). Verifiziert per Lasttest (autocannon -c 30 -d 10): CPU verteilt sich jetzt gleichmäßig auf allen 3 Replicas (~100% je Container) statt vorher 133% auf einem Kern. Prisma-Pool per Replica aufDB_POOL_MAX=10gecappt (3 x 10 = 30, weit unter dem Supabase-Limit von 200 Max Client Connections).Voller Runbook-Stand in
docker/SCALING-ROADMAP.mdim Repo, auch inCLAUDE.md/README.mdvermerkt. Zweiter physischer Server weiterhin nicht nötig.