Dies wird wahrscheinlich nicht direkt durch den Reverse-Proxy verursacht.
Für API-erstellte Beiträge verwendet Discourse DistributedMemoizer um PostsController#create, um eine doppelte API-Beitrags-Erstellung zu vermeiden. Dieser Memoizer nutzt einen Redis-basierten DistributedMutex mit einer sehr kurzen Gültigkeitsdauer von 1 Sekunde. Die Warnung bedeutet, dass die Erstellung bzw. Serialisierung des Beitrags innerhalb dieser Sperre länger als erwartet dauerte.
Also:
- Wenn der API-Beitrag trotzdem erfolgreich erstellt wird, ist dies eine Warnung und nicht die eigentliche Fehlerursache;
expected max: 1 secs, took an extra 1 secsbedeutet, dass die Sperre etwa 2 Sekunden lang gehalten wurde;- Es ist wahrscheinlicher, dass dies mit Serverleistung, Redis-/Postgres-Latenz, Festplatten-I/O, CPU-/RAM-Last, Plugins oder langsamer Nachbearbeitung zusammenhängt als mit dem Reverse-Proxy nginx/1Panel selbst;
- Der Grund, warum dies nur beim Posten über die API auftritt, ist, dass dieser Memoizer-Pfad für API-Anfragen verwendet wird.
Zu prüfende Punkte:
- Wird die API-Anfrage erfolgreich ausgeführt und nur ein Beitrag erstellt?
- Wie lange dauert die API-Anfrage auf der Client-Seite?
- Sind CPU, Arbeitsspeicher, Swap oder Festplatten-I/O während des API-Postens ausgelastet?
- Befinden sich Redis und Postgres im selben Container/Host, und sind sie funktionsfähig?
- Tritt die Warnung auch bei einem sehr kleinen reinen Textbeitrag ohne Bilder/Uploads noch auf?
- Sind nicht-standardmäßige Plugins installiert?
Da es sich um eine 1Panel-/Container-Bereitstellung und nicht um die Standard-Discourse-Docker-Installation handelt, kann es auch sinnvoll sein, dies bei einer offiziell unterstützten Installation nachzuvollziehen, bevor es als Fehler im Discourse-Kern behandelt wird.