ORM und Sessions (Datenbank Connection pooling)

[AnfängerDB]

Hallo ,


ich habe eine Frage im bezug auf ORM und Sessions.

Ich habe eine Flask (Web-)Anwendung gecoded, diese nutzt eine PostgreSQL-Datenbank, auf diese greife ich mit der OR-Mapper Flask-SQLAlchemy zu, aber immer wenn ich die (Flask-) Anwendung starte, werden mindestens 4 (Datenbank)Sessions geöffnet.

Meine Frage lautet:

• Wie viele Sessions brauch man grundliegend ?
• Wie kann man sowas für eine Anwendung ermitteln ?
• Gibt es zu viele Sessions die man öffenen kann ? Was wäre die Folge daraus ?

Über konstruktive Hilfe/Beiträge zu meiner Frage würde ich mich sehr freuen.

MfG

 

[akretschmer]

1. grundlegend reicht 1
2. man kann in PG auf pg_stat_activity schauem, da sieht man offene / aktive Verbindungen
3. die Anzahl der max. gleichzeitigen aktiven Verbindungen ist limitiert, Du kannst 'out of resources' gehen

Möglicherweise öffnen Dein Mapper mehrere Verbindungen, um einen Pool aufzubauen. Aber dazu kenne ich das Zeugs zu wenig...

 

[AnfängerDB]

1. grundlegend reicht 1
3. die Anzahl der max. gleichzeitigen aktiven Verbindungen ist limitiert, Du kannst 'out of resources' gehen

Möglicherweise öffnen Dein Mapper mehrere Verbindungen, um einen Pool aufzubauen. Aber dazu kenne ich das Zeugs zu wenig...

Ahh okay, danke für die Antwort:

Ich bin am überlegen wie viele Verbindungen reichen also was ist zu wenig, was ist möglicher Weise zu viel. Meine (Web-)Anwendung muss in der Spitze im höheren dreistelligen Nutzer klarkommen.

 

[castorp]

Meine (Web-)Anwendung muss in der Spitze im höheren dreistelligen Nutzer klarkommen.

Nach meiner Erfahrung sollten dafür etwa 10-15 Verbindung im Pool ausreichen. Vermutlich sogar weniger.

Wir betreiben hier Seiten mit > 10.000 aktiven Benutzern und da reichen Pools mit ~200 Verbindungen (die Hardware der Datenbank muss natürlich entsprechend leistungsfähig sein).

Es hängt natürlich stark von der Art der Anwendung ab. Meistens sind es nur wenige Anfragen die gleichzeitig abgearbeitet werden müssen, weil die Benutzer mehr Zeit damit verbringen den Inhalt des Bildschirms zu lesen, anstatt aktiv eine Abfrage auszulösen.

Ein häufiger Fehler beim Optimieren der Poolgröße ist, dass man den Pool zu groß macht. Dann wird nämlich die Datenbank überlastet und alles wird langsamer. Es ist besser in der Anwendung auf die Freigabe einer Verbindung aus dem Pool zu warten, als auf die Beendigung der Datenbankabfrage.

 

[AnfängerDB]

Nach meiner Erfahrung sollten dafür etwa 10-15 Verbindung im Pool ausreichen. Vermutlich sogar weniger.

Wir betreiben hier Seiten mit > 10.000 aktiven Benutzern und da reichen Pools mit ~200 Verbindungen (die Hardware der Datenbank muss natürlich entsprechend leistungsfähig sein).

Es hängt natürlich stark von der Art der Anwendung ab. Meistens sind es nur wenige Anfragen die gleichzeitig abgearbeitet werden müssen, weil die Benutzer mehr Zeit damit verbringen den Inhalt des Bildschirms zu lesen, anstatt aktiv eine Abfrage auszulösen.

Ein häufiger Fehler beim Optimieren der Poolgröße ist, dass man den Pool zu groß macht. Dann wird nämlich die Datenbank überlastet und alles wird langsamer. Es ist besser in der Anwendung auf die Freigabe einer Verbindung aus dem Pool zu warten, als auf die Beendigung der Datenbankabfrage.

Okay, danke für dein Feedback. Gibt es ein Tool (möglichst kostenlos ;-) ) mit den man sowas Messen kann ? Info: Das OS des Datenbank-Servers ist ein FreeBSD

 

[castorp]

Gibt es ein Tool (möglichst kostenlos ;-) ) mit den man sowas Messen kann ?

Die Kugel zwischen Deinen Schultern

Letztendlich musst Du die Performance Deiner Anwendung beobachten. Es hängt auch viel davon ab, wie leistungsfähig Dein Datenbankserver ist. Bei einem Server mit 250 CPU, ein RAID mit 10 NVMe SSD und 512 GB RAM werden die optimalen Werte anders aussehen, als mit einem Server mit 4 CPU, einer SATA SSD und 4 GB RAM.

Bei 500 gleichzeitigen Benutzern glaube ich nicht, dass Du mehr als 10-15 Verbindungen im Pool brauchen wirst.

Falls Dein Pool das unterstützt, dann konfiguriere das Logging so, dass entsprechende Warnungen ausgegeben werden, wenn die Anwendung zu lange auf eine Verbindung aus dem Pool warten muss (z.B. länger als 100ms). Wenn das zu häufig vorkommt, dann kannst Du ja die Anzahl moderat erhöhen.

Ich würde die Extension [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html) installieren und aktivieren (meiner Meinung nach sollte die Teil des Postgres Core werden und immer eingeschaltet sein). Dann kannst Du beobachten ob es irgendwelche Statements gibt die zu langsam laufen (und damit eine Verbindung im Pool blockieren).

Alternativ (oder zusätzlich) kannst Du [log_min_duration_statement](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-MIN-DURATION-STATEMENT) verwenden um langsame Statements im Logfile zu protokollieren.