Google Cloud SQL ist langsam

Question

Ich habe eine Cloud SQL-Instanz der Größe D0. Wenn ich eine einfache

select * from table 

laufen, die um 500 Zeilen hat, dauert es im Durchschnitt 100 ms auszuführen (wie von SQL Prompt berichtete). Während es in meiner lokalen Instanz von MySQL 5.5 nur 1 ms dauert. Meine Dev-Maschine hat 2,9 GHz Dual Core Intel Core i7 und 8 GB 1600 MHz Speicher. Ich habe in einem FAQ gelesen, dass die Leistung von db von der Größe abhängt - größere Instanzen haben mehr RAM und CPU.

Ist es vernünftig zu erwarten, dass Leistungsprobleme mit einer größeren Instanzgröße behoben werden? Oder verpasse ich hier etwas anderes?

Answer 1

1. Wohin verbinden Sie sich mit Ihrer Cloud SQL-Instanz?
2. Die Tier-Größe hat einen großen Einfluss auf die Leistung. Sie können die Stufe der Instanz vorübergehend ändern, um sie zu testen.

Answer 2

EDIT: 10. April 2016

GAE bietet jetzt Second Generation Cloud mysql, wo sogar eine gemeinsamen Grund wie 'db-g1-small' führt so schnell wie ein D8 Tier in dem alten Cloud SQL-Angebot . Es ist auch deutlich billiger. Dies scheint ein großer Meilenstein zu sein und es gibt keinen Grund mehr, auf Hacks und Workarounds zurückzugreifen.

Sie können sich auf die Cloud SQL-Preisgestaltung beziehen, aber die ungefähren Mindestkosten liegen bei 20 US-Dollar pro Monat.

ORIGINAL POST

Google Bestimmungen nur die VM auf einem langsamen Feld für die Tier-D0. Sie könnten D4 wählen, aber RAM ist nicht das Hauptproblem so viel wie der Prozessor (sie erwähnen nicht die GHz).

Netzwerklatenz ist nicht das Problem. Für z.B. Die folgenden 0.05s sind die Ausführungszeit der Abfrage auf dem Server. Jegliche Zeit danach könnte für die Datenübertragung aufgewendet werden.

mysql> select * from tracking limit 5; 
+--------------------------------+-----------+-----------+ 
| id        | scan_date | status | 
+--------------------------------+-----------+-----------+ 
| 420006929400111899561510697350 | NULL  | Delivered | 
| 420010859400111899561989496058 | NULL  | Delivered | 
| 420019849400111899561989496331 | NULL  | Delivered | 
| 420100109400111899561903290311 | NULL  | Delivered | 
| 420100319400111899561944407020 | NULL  | Delivered | 
+--------------------------------+-----------+-----------+ 
5 rows in set (0.05 sec) 

Edit: März 2016

Für mehrere Anwendungen verwende ich nicht mehr Cloud SQL und verwenden Sie einen remote gehostete Grund MySQL Cluster statt, da GAE Outbound-Socket-Verbindungen geöffnet. Klingt verrückt? Nicht in Übereinstimmung mit den Zahlen - das Senden einer Abfrage und das Zurückholen von Daten über diese Socket-Verbindung ist schneller als eine gemeinsam angeordnete D3.

Answer 3

Ansichten waren die Ursache für schlechte Leistung. Google führt seine eigene Variante der MySQL-Engine aus, die so optimiert ist, dass sie die Ansichten verletzen kann. Wenn Sie viele Joins haben oder/und Gewerkschaften erwarten, dass Ansichten langsam ausgeführt werden.

Aber es ist fast ein Jahr her, seit ich diese Frage gestellt habe und die Dinge könnten sich geändert haben. Ich habe die Ansichten nicht wieder aufgegriffen, seit wir uns von ihnen entfernt haben.

Answer 4

Wir hatten auch das gleiche Problem. Mit einer D16-Instanz würde eine einfache Website-Forenseite mehr als 10 Sekunden dauern. Ich habe gerade mit einem technischen Berater von Google Cloud gesprochen, der bestätigt, dass CloudSQL nicht wirklich bereit für "Leistung" ist (ab Sommer 2015), und er empfahl, alles neu zu schreiben, um DataStore zu verwenden ...

Also, wenn Sie Seiten haben, die Dutzende von kleinen SQL-Abfragen machen, und ein Dataset, das zu groß ist, um vollständig in den Cache zu passen, dann ist CloudSQL keine praktikable Lösung.