To begin with, we have to be clear that comparing Cloud SQL to any other product or service is not an exact comparison, as there are different features, implementations, etc. between any two surface-similar SQL services. Nonetheless, we can still reason about Cloud SQL without needing to bring in a technical analysis of a third-party service.
There are many factors which could influence the fetch time on a query. You say that there's no issue in executing the queries, and I'm assuming this means that you've checked on-instance statistics to see that your indexes are enabling a fast query time. The issue is in "fetching" as separated from the execution of the query. The definition of "fetch" is important here: there could be other variables influencing perceived "fetch" time depending on how you measure it, whether, due to your benchmark's methodology, you might also be including the time necessary to transform the data into programming-language objects, etc.
I'm curious how you diagnose this latency; how are you fetching the data? What network topology is involved? Is the computer fetching the data far from the instance? You could see wildly different network transfer times depending on this factor. There's also the issue of the performance statistics of the fetching computer, and the manner in which the "fetch" is triggered.
Feel free to update the thread with some information which responds to the above questions, and we should be able to narrow-down what the issue is. 23 seconds can even in fact be a reasonable time, all things dependent. We can't know until we speak more specifically about how everything is being done.
On Thursday, November 19, 2015 at 9:52:17 AM UTC-5, Elia Palme wrote:
-- There are many factors which could influence the fetch time on a query. You say that there's no issue in executing the queries, and I'm assuming this means that you've checked on-instance statistics to see that your indexes are enabling a fast query time. The issue is in "fetching" as separated from the execution of the query. The definition of "fetch" is important here: there could be other variables influencing perceived "fetch" time depending on how you measure it, whether, due to your benchmark's methodology, you might also be including the time necessary to transform the data into programming-language objects, etc.
I'm curious how you diagnose this latency; how are you fetching the data? What network topology is involved? Is the computer fetching the data far from the instance? You could see wildly different network transfer times depending on this factor. There's also the issue of the performance statistics of the fetching computer, and the manner in which the "fetch" is triggered.
Feel free to update the thread with some information which responds to the above questions, and we should be able to narrow-down what the issue is. 23 seconds can even in fact be a reasonable time, all things dependent. We can't know until we speak more specifically about how everything is being done.
On Thursday, November 19, 2015 at 9:52:17 AM UTC-5, Elia Palme wrote:
Hi,we just migrated our DB from Amazon RDS to Google SQL. On Amazon our instance was a (db.r3.large 2 CPU 15GB of RAM) on Google SQL we have selected the D32 with 16GB of RAM.The migration worked ok and we transferred 40GB of data from AWS to Google Cloud. The two DBs have been set up with the same flags (innodb_flush_log_at_trx_commit=2,innodb_file_per_ table=ON, etc.) The problem is that we are experiencing very slow data fetch. The issue in not in executing the queries, almost all our queries can use indexes and are very quick to execute.The issue in in the fetching, some time a query need 23 seconds of fetch time, if we re-run the same query the second time is very fast less than a second (I assume because data have been loaded in memory).On Amazon RS we did not have this kind of issue, however we did have the Provisioned IOPS option which was probably helping a lot.How can we improve the fetch time? Is it possible to have a SQL instance with Provisioned IOPS or running on SSD disks?ThanksElia
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/71b0caea-cb3e-41d1-b0ad-db19e722e7ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment