Google Cloud SQLが遅い

Question

D0サイズのCloud SQLインスタンスがあります。私がシンプルなものを実行すると、約500行の行があるので、実行には平均100ミリ秒かかる（SQLプロンプトによって報告されるように）。ローカルのMySQL 5.5では、1ミリ秒しかかかりません。私の開発マシンは2.9GHzのデュアルコアIntel Core i7と8GB 1600MHzのメモリを持っています。私はFAQで、dbのパフォーマンスはサイズに依存していると読んでいます - 大きなインスタンスにはRAMとCPUが増えています。

インスタンスサイズを大きくするとパフォーマンスの問題が解決すると予想されますか？それとも私はここに何か他のものを逃している？

Answer 1

1. どこからCloud SQLインスタンスに接続していますか？
2. 層のサイズはパフォーマンスに大きな影響を与えます。インスタンスの層を一時的に変更してテストすることができます。

Answer 2

EDIT：2016年4月10日

GAEは現在、 'DB-G1-small' のようにも基本的な層は古いクラウドSQLの提供に早くD8階層として行う第2世代のクラウドMySQLを提供しています。それはまた、大幅に安価です。これは大きなマイルストーンと思われ、ハックや回避策にはもう必要以上の理由はありません。

Cloud SQLの価格設定を参照できますが、おおよその最小コストは月額約20ドルです。 D0層のための遅いボックスに

ORIGINAL POST

Googleが規定VMを。あなたはD4を選択することができますが、RAMはプロセッサほど重要な問題ではありません（GHzは言及していません）。

ネットワーク遅延は問題ではありません。例えば、以下の0.05秒は、サーバー上の照会実行時間のみです。その後の時間は、データ伝送に費やすことができます。

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) 

編集：私は、もはやクラウドSQLを使用していないし、GAEは、アウトバウンドソケット接続を開いてから代わりにリモートでホストされている基本的なMySQLクラスタを使用する複数のアプリケーションのために2016年3月

。狂ったように聞こえる？数字によるのではなく、このソケット接続を介してクエリを送信してデータを戻すことは、同じ場所にあるD3よりも高速です。

Answer 3

ビューのパフォーマンスが低下しました。 Googleは、ビューを傷つけるような方法で最適化されたMySQLエンジンの独自のフレーバーを実行します。ジョインや結合が多い場合は、ビューの実行が遅くなることが予想されます。

しかし、私はこの質問を投稿してから事態が変わった可能性があります。私はそれらを使用しなくなってから再訪していません。

Answer 4

同じ問題がありました。 D16インスタンスの場合、単純なWebサイトのフォーラムページは10秒以上かかることがあります。 私は、CloudSQLが本当に「パフォーマンス」の準備ができていないことを確認した（2015年夏）、GoogleCloudの技術サポートエンジニアと話をしたところ、データストアを使用するためにすべてを書き直すことをお勧めしました...

小さなSQLクエリを作成するページがあり、キャッシュに完全に収まらないほど大きなデータセットがある場合、CloudSQLは現時点で実行可能な解決策ではありません。