11
Wenn ich einen Server mit 1 Kern habe, wie viele Puma Worker, Threads und welche Datenbankpoolgröße ist angemessen?Worker, Threads & Poolgröße mit Puma
Was ist der allgemeine Daumen hier?
A
Antwort
8
Keine einfache Antwort.
Die beiden wichtigsten Informationsquellen sind:
- Puma github repository (der Sicht der Autoren)
- Heroku's web page (Hauptpunkt der großen Benutzer-Sicht)
Leider inkonsistent sie sind vor allem, weil heroku verschiedene Deployment-Metriken und -Terminologie hat.
So landete ich im Anschluss an die Puma-Repository-Richtlinien bis die sagt:
- Ein Arbeiter pro Kern
- Themen im Zusammenhang mit RAM Verfügbarkeit und Anwendung und
- Themen = Connection Pool bestimmt werden
Also die Anzahl der Threads ist meist ein Versuch und überprüfen Sie die Operation.
Verwandte Themen
- 1. Log4net nicht Worker-Threads mit MinimalLock Modell
- 2. Puma/fehlende Protokolle
- 3. Puma auf Rails-Anwendung konfigurieren
- 4. Rails Puma Concurrency Problem
- 5. ASP.NET Performance: Worker Threads und I/O-Threads
- 6. Web Worker - erstellen sie tatsächliche Threads?
- 7. Perl Multithreading - Worker-Threads nicht mehr funktioniert
- 8. C# Beitritt Threads im Hintergrund Worker DoWork()
- 9. Beziehung zwischen Threads, Anwendungsdomänen und Worker-Prozesse
- 10. Konfigurieren von Puma und Sidekiq
- 11. Wie überwacht man einen Puma Server?
- 12. Heroku Speicherprobleme Puma mit
- 13. Sinatra Streaming mit Puma?
- 14. Heroku Schienen 4 + Puma-Einsatz
- 15. Rails App Verbindung Poolgröße, Vermeidung von Max Poolgröße Probleme
- 16. Mongodb/Mongoose PoolGröße Empfehlung
- 17. Sequelize Standardverbindung Poolgröße
- 18. Signale von mehreren Worker-Threads an den GUI-Thread senden
- 19. Lange laufende MSMQ-Nachrichtenverarbeitung. Die Begrenzung Worker-Threads zählen
- 20. Ein Leser-Thread, ein Writer-Thread, n Worker-Threads
- 21. Wildfly: Wie Worker-Threads in IO-Subsystem dynamisch
- 22. Anzahl der Threads pro Worker-Prozess erhöhen IIS
- 23. Java: Muster für die Überwachung von Worker-Threads?
- 24. Servlet Multi-Threading, die Stelle des Worker-Threads erstellt
- 25. Executorservice-Worker werden nicht in separaten Threads ausgeführt.
- 26. Kommunikation zwischen Haupt-Thread und Worker-Threads in Android
- 27. Korrekter Ansatz für vorübergehendes Anhalten eines Worker-Threads
- 28. JDBC-Verbindung Poolgröße unter JBoos
- 29. Beeinträchtigt die Anzahl der ausgelasteten Worker-Threads im CLR ThreadPool die Leistung von E/A-Threads?
- 30. Foreman/Puma nutzt nicht den angegeben Port in dev env
Die Richtlinie "Ein Arbeiter pro Kern" wird viel herumgeworfen, aber es ist im Grunde das Gegenteil von dem, was Heroku sagt (sie geben RAM als einzigen limitierenden Faktor für Arbeiter an und schlagen vor, dass Threads an verfügbaren Prozessor gebunden sein sollten). Hat jemand das letzte Wort dazu schon gegeben? Herokus Version macht für mich mehr Sinn, intuitiv. – robomc
Wie ich es verstehe, ist der wahre Vorteil der Arbeiter mit Puma Parallelität, da sie separate Ruby-Prozesse sind. Wenn Sie nur einen Kern haben, gibt es wirklich keinen Grund, mehr als einen Arbeiter zu verwenden, da sie nicht parallel laufen können. Dennoch könnte Heroku einige andere Effizienzverbesserungen bei der Verwendung mehrerer Worker selbst in einer einzelnen Kernumgebung entdeckt haben. –
Sie haben vollkommen Recht, und ich habe es als Teil der Richtlinien gesetzt: Ein Arbeiter pro Kern;) – tommasop