RootForum Community

Hallo,
Ich habe MySql auf einem 1und1 Server installiert und kann innerhalb des Servers problemlos zugreifen.
Von aussen ist der Zugriff jedoch extrem langsam, durchschnittlich 30 Kbit/s (also nicht mal 4KByte/s).
Dafuer, dass ich hier DSL habe scheint mir das doch etwas zu wenig zu sein.
Bei anderen Zugriffen (ftp, http, ...) funktioniert alles reibungslos.
An der DB-Konfiguration habe ich eigentlich nichts geaendert (installiert ist MySQL 3.23.52-Max-log von Suse 8.1), nur ein paar DBs angelegt.
Hat jemand eine Idee was die Ursache sein koennte?
vielen dank,
michael

Normal? Afaik sind Netzwerk-Verbindungen (ODBC) nie wirklich schnell, dafür aber wirklich unsicher. Ich kann Dir nur Raten, diesen Unfug schnellstmöglichst abzustellen oder aber zumindest aufs paranoideste abzusichern (mit allem wo gibt). Wofür brauchst Du denn die Verbindung überhaupt? Gibt es keine andere (sicherere) Möglichkeit, Dein Ziel zu erreichen?

Gibt es keine andere (sicherere) Möglichkeit, Dein Ziel zu erreichen?

Es gibt schon Alternativen, aber die sind halt etwas unkomfortabel.
Momentan mache ich es so, dass ich bei mysql fuer alle benutzer den Zugriff von aussen gesperrt habe. Wenn ich darauf zugreifen will aendere ich das und erlaube den Zugriff fuer einen bestimmten Benutzer von einer bestimmten IP (meiner).
Alternativ habe ich es schon ueber putty/ssh probiert (Ich glaube, das nennt man Tunneling, oder aehnlich). Hatte die Hoffnung, dass es auf diesem Weg vielleicht schneller laeuft, war aber nicht.

So'n Tunnel ist auf alle Fälle schonmal ein Schritt in die richtige Richtung :)

Ich bin zwar nicht so der Datenbankfachmann (hallo Jtb, *ex-user* - wo seid ihr?) und kann nur aus meinen Erfahrungen aus AE-Seite berichten.
Ich hab' halt die Erfahrung gemacht, dass ODBC-Connects (wie proprietäre Methoden übrigens auch) nie wriklich schnell waren. Das "schlimmste" waren immer die Phasen des Verbindungsauf- und -abbaus, die haben sogar auf localhost säuisch lange gebraucht. Insofern würde ich nie die Performace eines FTP o.ä. erwarten.
Ich hoffe und warte einfach mal auf die anderen, besser informierten ;)

MiSchmi wrote:Hallo,
Ich habe MySql auf einem 1und1 Server installiert und kann innerhalb des Servers problemlos zugreifen. Von aussen ist der Zugriff jedoch extrem langsam, durchschnittlich 30 Kbit/s (also nicht mal 4KByte/s).

Hat jemand eine Idee was die Ursache sein koennte?
vielen dank,
michael

Ursache? Der Fremdzugriff von außen.

Man sollte nie Datenbankzugriff von außen erlauben.
Schon mal aus Prinzip: generell NIE.

Wenn du deine "außen"-Verbindung nur zur Administration nutzt, dann wäre es wirklich besser, lokal auf dem Server ein Administrations-Interface zu installieren (php myAdmin oder sowas). Dieses kannst du dann per FTP an- oder abschalten (Berechtigungen mit CHMOD ändern, alle r/w/x Flags wegnehmen, bzw. dann alle gesetzten Flags wieder setzen), oder du nimmst eine .htaccess-Datei zur Zugriffsteuerung. CHMOD'en wär natürlich sicherer.

So bleibt alles lokal,
und trotzdem hast du ggf. deinen Zugriff, wenn du ihn brauchen solltest.

Der Aufwand ist in etwa der selbe.
Das umständliche Manipulieren der Datenbanknutzer entfällt.
Sieht gar nach weniger Arbeit aus als vorher.

pierro

pierro wrote:Man sollte nie Datenbankzugriff von außen erlauben.
Schon mal aus Prinzip: generell NIE.

1.: Prima Idee, wenn es sich bei dem DB-Server um ein Backend handelt ...
2.: Auch hat MiSchmi nichts von Administration gesagt
3.: Lass' ihn, wenn er unbedingt will ...
4.: Wenn Du keine Erkärung für das Phänomen hast oder Informationen hast wie sich die Transferrate steigern lässt, dann kannst Du Dich gerne, nachdem Du den Thread gelesen hast, ein wenig kürzer fassen.

MiSchmi: Eine Idee, naja eher einen Workaround hätte ich noch. Vielleicht könntest Du die Daten per Skript auf dem Server in eine Datei exportieren und komprimieren lassen und Dir dann die Datei per FTP ziehen? Andersrum ginge es genauso und Du hättest den problematischen Remote-Zugriff weg ...

Hi,

Man sollte nie Datenbankzugriff von außen erlauben.
Schon mal aus Prinzip: generell NIE.

das überzeugt mich ja schon wieder. Ich habe z.B. einen Server bei Purtec, auf dem NUR eine Datenbank läuft. Ein Vorteil hat deine "Aussage" natürlich; die Load wäre immer gleich 0, weil ja keiner zum DB-Server connecten kann...

Es kommt immer auf den Anwendungsbereich an, aber die Aussage "generell NIE" ist Schrott (sorry für die harten Worte). Man kann mysql auch wunderbar über die Benutzerrechte absichern; und wenn man dann noch festlegt "Zugriff nur von einer entsprechenen IP-Range", dann gibt es da noch nichtmal ein Sicherheitsproblem, denn selbst wenn jemand das Passwort mitbekommen sollte, dann hat er noch immer nicht die erforderliche IP.

In meinen Augen gibt es nicht "leichtsinnigeres" als MySQL und HTTP auf einem Server laufen zu lassen (auf einem Produktivsystem); denn wenn die Load durch HTTP mal auf über 120 steigt (hier schon mehrfach vorgekommen), dann raucht dir unter Umständen mySQL ab und zieht mal eben 1-2 Tabellen mit.

coolsurfer

Da hat er allerdings nicht ganz Unrecht mit. Aber wenn man's richtig machen will sollte man sich 2 Server bei einem Houser unterstellen und die direkt über den 2. Ethernet Port, den mittlerweile fast jeder 1U Server hat, verbinden. Dann lässt man den MySQL nur auf dem internen interface hören und gut ist. Das ist schnell, sicher und spart Traffickosten. So lassen sich auch gut IRC oder DNS-Server verbinden. Beim IRC-Server spart das sehr viel Traffic und bei DNS-Server lässt man die Zonen über das interne Interface abgleichen und hat damit bedeutend an Sicherheit gewonnen.

dea wrote:Prima Idee, wenn es sich bei dem DB-Server um ein Backend handelt ...

Und? Datenbank ist Datenbank bleibt Datenbank.

Dann schnibbel ich mir das DB-Interface soweit zurecht, bis es auf den Zweck paßt. Der Zweck einer Datenbank ändert nichts am Sinn des Wortes "Datenbank". Dann ist es halt ein "Backend-Interface" statt eines "Administrationsinterfaces". "Moonboots" sind auch bloß Schuhe.

oxygens Vorschlag ist auch nicht ohne ...
Paranoia kann nie falsch sein. Lieber zuviel als zuwenig.

Nur-Datenbank ist natürlich etwas anderes. Das ist aber nicht das hier beschriebene Szenario, und deshalb interessiert mich das auch nicht weiter.

dea wrote:2.: Auch hat MiSchmi nichts von Administration gesagt

Und? Woraus schließt du das? Bist du Hellseher?
Ich kann in den Postings nichts derartiges herauslesen ...

Wer etwas sagen will, soll es tun. Wer es läßt, ist selbst schuld.

dea wrote:3.: Lass' ihn, wenn er unbedingt will ...

Ich zwing niemand, sondern versuche nur, konstruktive Hilfe zu geben.

Dazu gehört auch ein kleiner Diskurs zum Thema Datensicherheit.
Was für dich Palaver ist, das überfliege.

Kritisieren ist sinnlos, es sei denn, die Antwort ist definitiv falsch.

dea wrote:Wenn Du keine Erkärung für das Phänomen hast oder Informationen hast wie sich die Transferrate steigern lässt, dann kannst Du Dich gerne, nachdem Du den Thread gelesen hast, ein wenig kürzer fassen.

Transferrate steigern?

Meine Datenbank hat SOAP-Interface für Rückgabe der Daten.
Lokale SQL-Abfrage, Ausgabe dagegen ist extern.

( Kurz genug? )

HTTP-Calls vom Client gehen IMMER schneller, als direkte Datenverbindung vom Client. Warum?

1. Die Connects zur DB werden IMMER lokal durchgeführt.
2. Der Client muß eben NICHT a) Datenbank aufmachen, b) Daten abfragen, c) Daten transferieren, d) Datenbank zumachen. Stattdessen muß der Client nur eine Anfrage stellen und kriegt dann in Rekordzeit die Antwort des Servers zurück. Viele unnötige Schritte entfallen.
3. Ein Cachen des Abfrageergebnis im Server (Rückgabe immer wieder an temp Variable im SOAP-Modul anhängen, erst dann Ausgabe) sorgt wiederrum dafür, daß es NOCH schneller geht.

Ist wie dein Vorschlag, erfordert aber mehr Sachkenntnis.

Nur müßte ich mich dann noch mehr auslassen, über SOAP::Lite, Parsen von XML in PHP und ähnlichen Dingen.

Das läßt sich natürlich genauso gut auch alles ergooglen.

Man kann IMMER darauf verzichten, in Details zu gehen. Leider sind Details aber meist wichtig, wenn sie ein großes Bild ergeben sollen.

Ich finde, dies sollte man niemandem vorwerfen.

pierro

Wenn du deine "außen"-Verbindung nur zur Administration nutzt, dann wäre es wirklich besser, lokal auf dem Server ein Administrations-Interface zu installieren (php myAdmin oder sowas).

Habe ich bereits, benutze ich momentan um den Zugriff von aussen zu (de-)aktivieren.
Das Problem ist nicht, dass ich von aussen einfach nur sql-statements ausfuehren will (im Endeffekt natuerlich schon). Ich habe lokal eine (eigene) Javaanwendung in der ich DB-Eintraege auf Objekte abbilde und diese dann manipuliere, bzw. neue erstelle.

Insofern würde ich nie die Performace eines FTP o.ä. erwarten.

Erwarte ich auch nicht, nur die Diskrepanz zwischen mysql und anderen Zugiffen scheint mir verdammt gross (30 Kbit gegenueber 700 Kbit).

Vielleicht könntest Du die Daten per Skript auf dem Server in eine Datei exportieren und komprimieren lassen und Dir dann die Datei per FTP ziehen?

Hatte ich auch schon gemacht, ich wuerde aber viel lieber die Daten direkt aus meiner eigenen Anwendung manipulieren.

In meinen Augen gibt es nicht "leichtsinnigeres" als MySQL und HTTP auf einem Server laufen zu lassen (auf einem Produktivsystem); denn wenn die Load durch HTTP mal auf über 120 steigt (hier schon mehrfach vorgekommen), dann raucht dir unter Umständen mySQL ab und zieht mal eben 1-2 Tabellen mit.

Ich habe nun mal nur einen Server. Als Webserver fuer das Prduktionssystem verwende ich Tomcat (alles ist dynamisch, es gibt keine statischen Seiten). Apache laeuft zwar auch, aber auf einem anderen Port, und nur zu Adminstrationzwecken (phpMyAdmin, Mantis).
P.S.: Ich bin neu hier und weiss nicht, wie ich bei den Zitatenn den urspruenglichen Verfasser angeben kann. Deshalb sind obige Antworten vielleicht etwas unuebersichtlich.

pierro wrote:Meine Datenbank hat SOAP-Interface für Rückgabe der Daten.

Hey, klinkt interessant. Hat zwar nicht mit meinem aktuellen Problem zu tun (?), aber die Moeglichkeit eines Zugriffs ueber SOAP macht mich neugierig. Wird das von irgendeiner DB angeboten (MySql), oder handelt es sich dabei um eine Eigenentwicklung?

Hi,

http://www.heise.de/ix/artikel/2002/07/118/

Als Anregung fuer PHP...


ich benutze sowohl Client als auch Server aus Eigenentwicklung, die Entwicklung von
sowas ist in PHP wirklich sehr simpel, Perl wird wohl auch recht einfach sein. ;)

(Das PEAR:SOAP enthält natürlich auch eine server.php) ;)

Gruss,

Out

MiSchmi,

ich denke, dein grundlegender Ansatz ist das Problem.

Du solltest nicht direkt in der Datenbank arbeiten, sondern stattdessen ein botschaftbasierendes System verwenden.

Die Datenbankverbindung hat ja erkennbar den großen Nachteil, daß sie hohe Antwortzeiten für die jeweilige Abfrage besitzt. Du sitzt also de facto mit einer DSL-Leitung an einer Datenbank, die eine Verbindung in Echtzeit erfordert.

Im LAN sind Pingzeiten unter 200 ms normal, im Internet dagegen nicht.

Deine 30Kbit/s sind rein theoretisch=hypothetisch und ergeben sich aus der Größe des Pakets und der jeweiligen Antwortdauer.

Würdest du aus 10 einzelnen Paketen (bspw. 1Paket=1024 Bytes) mit je 200-1000 ms Antwortzeit ein einzelnes Paket (10240 Bytes) mit der gleichen Antwortzeit machen, hättest du geschwindigkeitsmäßig schon viel gewonnen. Je mehr du in ein Paket packst, umso besser.

Der große Nachteil momentan (und Grund für den Geschwindigkeitseinbruch) ist, daß du durch die langen Pingzeiten der einzelnen Pakete deine Bandbreite niemals voll ausschöpfst.

Drum kriegste auch nur 4KB/sec.

Vorteil wäre, daß deine Anwendung auch über eine 9.600-Baud-Modem-Verbindung laufen würde, entsprechende Geduld vorausgesetzt ... aber das wäre bei einem botschaftsbasierenden System genau so. :-)

MiSchmi wrote:SOAP: Hey, klinkt interessant. Hat zwar nicht mit meinem aktuellen Problem zu tun (?), aber die Moeglichkeit eines Zugriffs ueber SOAP macht mich neugierig. Wird das von irgendeiner DB angeboten (MySql), oder handelt es sich dabei um eine Eigenentwicklung?

"Hat zwar nicht mit meinem aktuellen Problem zu tun?"
Doch ... botschaftsbasierendes System.

Nein, wird nicht von irgendeiner DB angeboten.
Es ist eine Entwicklung, die zum aktuellen Webstandard gehört.

Serverseitig:

Perl programmieren können, Perlmodul schreiben, Perlmodul testen, das Perlmodul als SOAP-Modul verwenden. Fertig.

Clientseitig:

Borland Delphi mit Indy Komponenten und Indy SOAP Komponenten (war mal auf der Homepage http://www.nevrona.com, kann jetzt noch unter ftp.nevrona.com liegen ... ), SOAP-Envelope und SOAP-Body vorbereiten, per HTTP (oder HTTPS) an einen Soap-Proxy POSTen.

Der Aufbau ist einfach:

- Clientprogramm sendet SOAP-Botschaft an den Server.
- Der Server hat einen SOAP-Proxy zum Parsen der Botschaften.
- Dieser Proxy leitet das SOAP-Paket an das entsprechende Perlmodul und die entsprechende Funktion weiter.
- Der Server antwortet mit dem Ergebnis der angesprochenen Funktion.

Eine SOAP-Botschaft sieht immer so aus (stark vereinfacht):
<SOAP-ENVELOPE >
<SOAP-BODY m:Funktionsname>
<PARAMETER1>PARAMETERWERT1</PARAMETER1>
<PARAMETER2>PARAMETERWERT2</PARAMETER2>
</SOAP-BODY>
</SOAP-ENVELOPE>

Request und Response unterscheiden sich hier kaum. Jeder hat den SOAP-Envelope (SOAP-Umschlag) und den SOAP-Body (SOAP-Inhalt).

Anleitungen dazu gibts unter http://www.soaplite.com.

SOAP::Lite ist SOAP, aber nur dessen Grundlagen ohne weiterführende Funktionen. Alles andere kann man sich dann selbst anprogrammieren, und das ist sowieso immer optimal.

pierro

pierro wrote:Würdest du aus 10 einzelnen Paketen (bspw. 1Paket=1024 Bytes) mit je 200-1000 ms Antwortzeit ein einzelnes Paket (10240 Bytes) mit der gleichen Antwortzeit machen, hättest du geschwindigkeitsmäßig schon viel gewonnen. Je mehr du in ein Paket packst, umso besser.

Klingt einleuchtend. Meine Anwendung verwendet natuerlich auch sehr viele Einzelanfragen. Aber ich habe auch schon auf einer lokalen DB gearbeitet und versucht die Daten mit
mysqldump <lokale db> | mysql <server db>
zu transferieren. Mit dem gleichen Ergebnis (sehr lahm). Wenn ich dich richtig verstehe muesste das doch dann schneller gehen.

pierro wrote:Nein, wird nicht von irgendeiner DB angeboten.
Es ist eine Entwicklung, die zum aktuellen Webstandard gehört. ... SOAP ...

Kleines Missverstaendnis. Ich denke, ich kenne mich mit SOAP bereits recht gut aus. Wenn auch eher aus der Java-Welt. Meine Frage zielte eher darauf ab, ob es eine DB gibt, die bereits eine solche Schnittstelle zur Verfuegung stellt (sozusagen SQL ueber SOAP).

MiSchmi wrote:Klingt einleuchtend. Meine Anwendung verwendet natuerlich auch sehr viele Einzelanfragen. Aber ich habe auch schon auf einer lokalen DB gearbeitet und versucht die Daten mit
mysqldump <lokale db> | mysql <server db>
zu transferieren. Mit dem gleichen Ergebnis (sehr lahm). Wenn ich dich richtig verstehe muesste das doch dann schneller gehen.

Eigentlich schon.

Aber deine Shell ist irgendwie lahm, und/oder dein mySQL ist lahm.
Manche Provider beschneiden beim Arbeiten auf der Shell dessen Bandbreite.

Sinn und Zweck der Shell ist ja nicht, große Datenmengen zu empfangen oder zu senden.
Sinn und Zweck sind simple administrative Tätigkeiten.
Und die sollen so sicher wie möglich sein.

Die meisten Sicherheitslücken beruhen nämlich darauf, mögliche Daten oder Parameter zu überladen, und damit das Programm zum Absturz oder zu einem Freistoß (root-access) zu bringen. Wer die Shell mit viel Zeugs zuballert, kann unter Umständen diese Effekte erreichen.

Das will man wohl tunlichst vermeiden.

Dein HTTP dagegen ist schnell. Oder?

Was hälst du davon, den Dump per HTTP-Upload hochzuspielen, und dann erst das INSERT zu machen? Von der temporären Datei des Uploads aus, die Datenbank von lokalem Server nach lokalem Server zu inserten?

Dann sparst du dir nämlich das langsame Transferieren der Daten über die Shell (oder mySQL), und nimmst dafür das schnellere HTTP zum Hochladen.

Kleines Missverstaendnis. Ich denke, ich kenne mich mit SOAP bereits recht gut aus. Wenn auch eher aus der Java-Welt. Meine Frage zielte eher darauf ab, ob es eine DB gibt, die bereits eine solche Schnittstelle zur Verfuegung stellt (sozusagen SQL ueber SOAP).

Jein.

Eine Datenbank mit direktem SOAP-Support ist mir nicht bekannt, aber es gibt SOAP-Interfaces für die Ã?bermittlung von SQL-Statements an eine ODBC-Datenquelle auf dem Server. (http://www.sqldata.com/soap.html)

Was ich meine, ist eine SOAP-Schnittstelle, die speziell auf deine DB und deren Verwendungszweck zugeschnitten ist.

Das ist auf jeden Fall besser, als das simple Weiterleiten einer Anfrage an die SQL-Datenbank. Dann hast du nämlich noch nicht viel mehr gekonnt (="SQL über SOAP") als Prozessorzeit zu verkloppen.

Schneller wird dadurch kaum etwas, außer das die Statements statt über lahmes mySql oder lahme Shell über schnelles HTTP gehen.

Aber das begrenzt ja nicht den Datenwust aus der Datenbank.

pierro