Langsame Flask-SQLAlchemy-Verbindung

[PythonCodingFun]

Hallo,

Und: mach' dich mal vom Connection Pooling frei. Es hat den Anschein, dass dein Fokus darauf dir den Blick auf's Gesamte verbaut und du dir dadurch selber im Weg stehst. Du hast auch immer noch nicht verraten, ob du wirklich so viele (parallele) Verbindungen aufbaust, dass das Connection Pooling überhaupt relevant wird.

Gruß, noisefloor

Der Connection pool ist default ohnehin auf 5 vorkonfiguriert Quelle Aber ich könnte ja mal den NullPool verwenden, den ich gerade entdeckt, oder auf 1 stellen habe einfach um zu testen ob ich falsch liege.

Die DB dient ja nur dazu das ein Nutzer Informationen (Text + Bild) zu geben, sprich mehr als "simple" CRUD Abfragen gibt es nicht.

[sparrow]

@PythonCodingFun: Wie genau "vermutest" du denn, welchen Einfluss die Anzahl der Verbindungen im Connection Pool auf dein Problem hat? Also warum denkst du, 5 oder 50 machen da einen Unterschied, wenn da überhaupt alle x Tage eine Abfrage läuft?

Es wurde nun wirklich ausführlich dargelegt, was du probieren solltest. So wichtig kann das Problem ja nicht sein, wenn du noch immer an dem Pool rumfummelst, statt die Abfrage mit psql einfach mal auf die kalte Datenbank los zu lassen.

[PythonCodingFun]

@PythonCodingFun: Wie genau "vermutest" du denn, welchen Einfluss die Anzahl der Verbindungen im Connection Pool auf dein Problem hat? Also warum denkst du, 5 oder 50 machen da einen Unterschied, wenn da überhaupt alle x Tage eine Abfrage läuft?

Es wurde nun wirklich ausführlich dargelegt, was du probieren solltest. So wichtig kann das Problem ja nicht sein, wenn du noch immer an dem Pool rumfummelst, statt die Abfrage mit psql einfach mal auf die kalte Datenbank los zu lassen.

Die Datenbank ist nicht das Problem, da ich es mit zwei verschiedenen DB und System probiert (Server vs. Raspberry PI) habe und den gleichen Effekt (mit der Web-App) habe.
Auf dem Server läuft parallel andere DB-Server (müssten zwei sein) der keine Probleme macht und schnell ist (da werden die Anfragen mit einem C-Programm realisiert) Aber auf diese DB-Server habe ich selbst keinen Einfluss. Diese laufen (fast) nahtlos 24/7. Ich nutze den Server nicht alleine und kann nicht einfach so die DB restarten. Um was Kaltzutesten

[DeaD_EyE]

https://stackoverflow.com/a/75515575/2817354

Also angeblich ist der Query in manchen Fällen sehr langsam, da SQLAlchemy erstmal etwas über die Struktur der Datenbank erfahren muss.
Dann spielt es auch keine Rolle, ob du nur eine oder 5 Verbindungen wählst, denn die Abfrage der Struktur kommt so oder so.

[PythonCodingFun]

https://stackoverflow.com/a/75515575/2817354

Also angeblich ist der Query in manchen Fällen sehr langsam, da SQLAlchemy erstmal etwas über die Struktur der Datenbank erfahren muss.
Dann spielt es auch keine Rolle, ob du nur eine oder 5 Verbindungen wählst, denn die Abfrage der Struktur kommt so oder so.

Ja danke aber das gilt für Async da gibt es auch bekannte Ansätze aber FLASK-SQLAlchm.... nutzt kein Async

[PythonCodingFun]

Messen statt vermuten, was das Problem ist.

Wie misst man richtig ? Welche Tools gibt es ? So ein Problem hatte ich vorher nicht. Bringt mir nicht viel zu sagen das ich messen nicht vermuten soll, wenn ich keine Ansätze bekomme, was hier für richtig gehalten wird.

[Sirius3]

Erster Schritt ist, ein Programm zu schreiben, das nur aus der langsamen Datenbankabfrage besteht, so dass man damit automatisiert genaue Timing-Messungen machen kann.
Wenn man dann nachgewiesen hat, dass diese Abfrage beim ersten mal langsam und bei weiteren schnell ist, kann man profile genau den Aufruf identifizieren, der langsam ist.

[DeaD_EyE]

Ja danke aber das gilt für Async da gibt es auch bekannte Ansätze aber FLASK-SQLAlchm.... nutzt kein Async

1. Asynchroner Code ist generell langsamer aufgrund des Overheads und des Intervalls mit denen Ereignisse abgefragt werden.
2. Auch asynchroner Code (geht mit SQLAlchemy) müsste zuerst die Abfrage tätigen, welche Struktur die Datenbank hat.

Das hat nichts mit synchroner vs. asynchroner Code zu tun und asynchroner Code würde das Problem nicht auf magische Weise beheben.

Mögliche Fehlersuche ohne Query, nur der Verbindungsaufbau:
1) Zeit des Verbindungsaufbaus ohne SQLAlchemy testen. Für PostgreSQL gibt es: https://www.freecodecamp.org/news/postgresql-in-python/
2) Zeit des Verbindungsaufbaus mit SQLAlchemy mit nur einer Verbindung testen.

Wenn bei SQLALchemy das Problem schon mit nur einer Verbindung hat, dann lösen mehrere Verbindungen das Problem der Abfrage auch nicht.
Wenn das Problem nur bei SQLAlchemy auftritt, dann liegt mit sehr hoher Wahrscheinlichkeit an der Abfrage der Datenbankstruktur.

[PythonCodingFun]

Ja danke aber das gilt für Async da gibt es auch bekannte Ansätze aber FLASK-SQLAlchm.... nutzt kein Async

1. Asynchroner Code ist generell langsamer aufgrund des Overheads und des Intervalls mit denen Ereignisse abgefragt werden.
2. Auch asynchroner Code (geht mit SQLAlchemy) müsste zuerst die Abfrage tätigen, welche Struktur die Datenbank hat.

Das hat nichts mit synchroner vs. asynchroner Code zu tun und asynchroner Code würde das Problem nicht auf magische Weise beheben.

Mögliche Fehlersuche ohne Query, nur der Verbindungsaufbau:
1) Zeit des Verbindungsaufbaus ohne SQLAlchemy testen. Für PostgreSQL gibt es: https://www.freecodecamp.org/news/postgresql-in-python/
2) Zeit des Verbindungsaufbaus mit SQLAlchemy mit nur einer Verbindung testen.

Wenn bei SQLALchemy das Problem schon mit nur einer Verbindung hat, dann lösen mehrere Verbindungen das Problem der Abfrage auch nicht.
Wenn das Problem nur bei SQLAlchemy auftritt, dann liegt mit sehr hoher Wahrscheinlichkeit an der Abfrage der Datenbankstruktur.

Ne Flask-SQLAlchemy ist nicht SQL-Alchemy, klar SQL-Alchemy nutzt Async (optional) aber Flask-SQLAch... nicht jedenfalls finde ich nix in der doc. und ich nutze keine Asynchronität der Web-App (u.a wegen des von dir erwähnten Overheads und ich brauch das nicht in der Anwendung).

Aber die Fehlersuche die von dir geschrieben hast ist aber interessant. muss ich testen.

[Dennis89]

Ne Flask-SQLAlchemy ist nicht SQL-Alchemy, klar SQL-Alchemy nutzt Async (optional) aber Flask-SQLAch... nicht jedenfalls finde ich nix in der doc.

Hmm, gleich auf der Startseite von Flask-SQLAlchemy steht:

Flask-SQLAlchemy does not change how SQLAlchemy works or is used. See the SQLAlchemy documentation to learn how to work with the ORM in depth. The documentation here will only cover setting up the extension, not how to use SQLAlchemy.

https://flask-sqlalchemy.readthedocs.io/en/3.1.x/



Grüße
Dennis

[PythonCodingFun]

Ne Flask-SQLAlchemy ist nicht SQL-Alchemy, klar SQL-Alchemy nutzt Async (optional) aber Flask-SQLAch... nicht jedenfalls finde ich nix in der doc.

Hmm, gleich auf der Startseite von Flask-SQLAlchemy steht:

Flask-SQLAlchemy does not change how SQLAlchemy works or is used. See the SQLAlchemy documentation to learn how to work with the ORM in depth. The documentation here will only cover setting up the extension, not how to use SQLAlchemy.

https://flask-sqlalchemy.readthedocs.io/en/3.1.x/

Okay, ich hatte nach einem Async in der doc gesucht, okay. danke Da hatte ich mich geirrt. Aber das ändert nix daran das ich keine Async funktionalität nutze.

[Sirius3]

Es ist auch völlig unerheblich, ob da was asynchron passiert, denn das hat auf die Geschwindigkeit keinen merklichen Einfluß. Auch hier hätte man wieder vorher messen sollen, bevor man den OP auf eine falsche Fährte lenkt.
Wie man mißt hatte ich ja schon mehrfach geschrieben. Solange in diese Richtung nichts passiert, ist alles weitere Spekulation.

[PythonCodingFun]

Es ist auch völlig unerheblich, ob da was asynchron passiert, denn das hat auf die Geschwindigkeit keinen merklichen Einfluß. Auch hier hätte man wieder vorher messen sollen, bevor man den OP auf eine falsche Fährte lenkt.
Wie man mißt hatte ich ja schon mehrfach geschrieben. Solange in diese Richtung nichts passiert, ist alles weitere Spekulation.

Ja das mache ich noch, nur habe ich noch andere Baustellen an denen ich auch Arbeiten muss, denn die Anwendung ist zwar nicht so schnell in Punkto DB-Abfragen aber sie läuft stabil (bisher) und ist (wohl) fehlerfrei weitesgehend. Aber ich finde es trotzdem extrem nett (von Euch allen) das ich weitere Ideen bekomme.