Zugriff auf externe Datenbank sehr langsam

[Niko310391]

Hallo,

ich habe einen Online-Server, auf dem eine Datenbank liegt. Nun habe ich mir am Wochenende eine Testumgebung in XAMPP eingerichtet, in der ich eine Verbindung zur externen Datenbank herstelle. Diese funktioniert soweit auch super, allerdings führt diese zu deutlich längeren Ladezeiten der Seite (eine Seite, die vorher max. 1 Sekunde geladen hat, braucht nun >10 Sekunden). Verbinde ich mich mit der in XAMPP eingerichteten DB, sind die Ladezeiten wieder normal.

Laut meinem Server-Provider liegt es nicht an denen. Kann ich dieses Problem irgendwie beheben?

Gruß
Niko

[Nobbie]

Kann ich dieses Problem irgendwie beheben?

Nein. Auf einen "remote" Server zuzugreifen bedeutet riesiger Datentransfer. Bei jedem "SELECT" werden ALLE Treffer über die Leitung gejubelt, erst auf dem Xampp Rechner wird danach entschieden, welche Daten wirklich verarbeitet werden (angezeigt werden, geändert werden usw.). Wenn also beispielsweise "Select * From ..." irgendwo steht (ohne weitere LIMIT Klausel) und in der entsprechenden Tabelle sind beispielsweise 10.000 Datensätze gespeichert, dann werden alle 10.000 Datensätze transferiert. In Fachsprache ausgedrückt wird die komplette sog. "Fundstelle" transferiert. Das kann dauern....

Auf dem internen LAN oder gar auf dem gleichen Rechner geht das um Faktoren schneller, im Internet von Rechner zu Rechner beschränkt die Download Speed den Transfer. Der mag Dir zwar schnell erscheinen, wenn Du beispielsweise 50Mbit hast, aber intern auf Deinem Rechner dürfte die Transfergeschwindigkeit zwischen zwei Prozessen um Faktor 100 bis 1000 schneller sein. Deswegen läuft es lokal auch schnell, aber nicht "remote". Internetgeschwindigkeit ist viel zu langsam für diese Infrastruktur.

[Niko310391]

Hmm...das ist blöd, aber wohl leider nicht zu ändern...
Trotzdem danke für die Information

[Nobbie]

Hmm...das ist blöd, aber wohl leider nicht zu ändern...

So ganz hoffnungslos ist es nicht, denn das Verhalten hängt auch maßgeblichst davon ab, wie die Datenbankzugriffe programmiert sind. Wenn man nämlich weiß, dass dieser I/O (der Transfer der Daten aus dem Select in das PHP Script) der Bottleneck ist, dann kann ein guter und geübter SQL-Programmiere da durchaus einiges machen, man muss nämlich schauen, dass man die sog. "Fundstelle" möglichst klein hält. Je kleiner die jeweiligen Fundstellen, umso weniger Daten werden transferiert und umso schneller geht das dann.

Nur haben die meisten "Script-Kiddies" (so nenne ich die Programmierer der ganzen CMS a la WordPress, Joomla und wie sie alle heißen) überhaupt keine Ahnung von Infrastruktur und guter SQL Programmierung. Da wird unsauber getrennt, was auf dem Datenserver geschieht und was auf dem Apache Server geschieht, oftmals nämlich derselbe Rechner, da fällt das nicht so auf. Da werden gigantische Fundstellen generiert (die Katastrophe ist der allseits beliebte "Select * FROM Table" ohne jede weitere Bedingung), einfach weil "es geht". Und dann wird die ganze Fundstelle im PHP Code abgegrast und die Zeilen herausgepickt, die es für die aktuelle Verarbeitung benötigt. Hätte man das richig programmiert, würde man mit WHERE Klauseln und LIMIT Anweisung gezielt nur die paar Sätze aus der Datenbank holen, die wirklich gebraucht werden. Davon haben diese Script-Kiddies keine Ahnung. Und deswegen haben diese ganzen CMS auch teilweise grausame Laufzeiten selbst auf Systemen, wo die Datenbank nicht remote liegt.

Aber spätestens, wenn so etwas versucht, wie Du es gerade vorhast, dann sinkt die IO-Geschwindigkeit um exponentielle Werte und auf einmal dauert ein scheinbar simpler Datenzugriff ätzend lange, weil idiotisch viele Daten physikalisch über die Leitung gehen.

Da liegt die einzige Hoffnung und Möglichkeit für Dich, wenn es sich um Software handelt, die Du selbst programmiert hast. Da könntest Du gezielt eingreifen und versuchen, die Fundstellen so klein wie möglich zu halten. Aber wenn das Fremdprogramme sind, dann hast Du keine Chance, da blickt auch keiner durch (das ist teilweise Kraut und Rüben, was da zusammenprogrammiert wird) und außerdem könntest Du später keine Updates einspielen, weil dann jedesmal Deine "Optimierungen" zerschossen werden. Also es ist durchaus etwas machbar, aber eben nur dann, wenn man selbst programmiert.

[Niko310391]

Es handelt sich hierbei um ein selbst programmiertes Projekt...allerdings habe ich keine "SELECT * FROM Table" Befehle eingebaut...zum Einen arbeite ich mit den genauen Spalten, die ich benötige und zum Anderen halt auch mit Bedingungen...es gibt lediglich ein paar Count-Funktionen, die ein SELECT * FROM Table ohne jegliche Bedingung haben...

[Nobbie]

Wenn nichts mehr geht, dann geht nichts mehr, es ist und bleibt eben langsamer via Internet. Wobei man beispielsweise auch enorm viel gewinnen kann, wenn man "zeilenweise" arbeitet. Beispiel:

Man wählt eine bestimmte Menge an Datensätzen aus und stellt die benötigten Spalten im Select zur Verfügung. Das würden die meisten so programmieren:

Select Spalte1, Spalte2, Spalte3, Spalte4 .... FROM Table WHERE ....

und dann aus der Fundstelle einen Satz nach dem anderen "fetchen". Das ist eigentlich auch nicht falsch, aber ich habe selbst auch viel experimentiert und man kann dieses Scenaria unglaublich beschleunigen (das sind Faktoren!), wenn man stattdessen so programmiert:

Select id FROM Table WHERE ....

Damit erstellt man in der Fundstelle nicht ein komplette Tabelle mit den ganzen Spalten, sondern man selektiert nur den Primärschlüssel (die WHERE Klausel usw. bleibt die gleiche). Anschließend fetched man sich durch die Primärschlüssel (aber das sind natürlich vergleichsweise wenige Daten) und selektiert jeweils mit dem vorhandenen Schlüssel die notwendigen Spalten:

mysqli->fetch....(...) ---> ergibt jeweils einen aktuellen Primärkey und damit selektiert man genau einen Satz

Select Spalte1, Spalte2, Spalte3, Spalte4 ... FROM Table WHERE id = $id ($id ist genau er vorher ermittelte Primärschlüssel).

Und man loopt sich da über die ganzen Schlüssel und holt sich dann per Select jeden Satz einzeln. Man würde denken, das muss doch viel langsamer sein, weil ich jetzt pro Datensatz nochmal einen Select durchführe, während man im ersten Fall nur einen Select hat und damit die ganze Fundstelle ermittelt. Aber das ist genau das tückische, die Selects werden rasend schnell vom Interpreter abgearbeitet (das ist schiere CPU Performance), aber die fette Fundstelle, die ich im ersten Fall konstruiere, die verursacht hohen Traffic, es ist viel performanter, stattdessen einzeln die Sätze über die Leitung zu schicken. Natürlich hat auch das Grenzen und wer im ersten Fall auch gezielt mit richtigen LIMIT Klauseln die Fundstelle optimiert, wird ggf. nur wenig Unterschied feststellen. Das muss man ausprobieren. Aber viele Programmierer verschenken da irrsinnig viel Ressourcen, einfach weil sie es nicht merken. Aber wenn der Server via lahmer Internetleitung kontaktiert wird (und das kann noch so schnell sein, es ist um Faktoren langsamer als interner Traffic auf einem PC zwischen zwei Prozessen), dann bemerkt man das sofort. Probiert nur kaum einer aus.