我们按照Google Cloud SQL的说明清空了我们的表,并将其导入到第二代Google Cloud SQL实例中。
我们非常期待看到我们的数字在“谷歌硬件”上运行的情况。
通过使用Apache的
当我们深入挖掘时,真正令我们惊讶的是像这样的简单计数查询:
我可以多次重复查询,性能相同。 在我的 MacBook Pro 2017 上运行相同的查询,使用完全相同的转储:
更荒谬的是,正如您在上面看到的那样,我从未对默认的mysql安装进行任何调整,因此它仅在我的Macbook上使用125MB的RAM,而Google Cloud实例可用的RAM为10GB。
我们尝试将Google Cloud SQL实例大小增加到db-n1-highmen-8(8vCPU和52GB RAM!),但性能没有提高(如果我们从db-n1-standard-4降低,我们会看到性能下降)。
最后,使用这个问题,我们可以确认我们的数据库只有46GB,但在导入期间,Google Cloud SQL中的存储使用量不断增长,直到达到荒谬的74GB……我们不知道这是否是由于二进制日志记录(在Google Cloud SQL上默认启用,在我的本地机器上关闭)。
那么……有没有人在生产中使用Google Cloud sql? :)
更新:我们使用完全相同的.sql转储,并将其加载到一个db.r4.large AWS RDS中(因此具有相同的CPU / RAM),并在查询中获得了一致的0.50秒性能,并且也没有超过46GB的实例。
我们非常期待看到我们的数字在“谷歌硬件”上运行的情况。
通过使用Apache的
ab
进行Rails应用程序的压力测试,我们发现完成时间比预期慢了150毫秒,而且我们注意到ActiveRecord在相同页面上比我们的生产服务器(裸机)多花费了30毫秒到50毫秒的时间。当我们深入挖掘时,真正令我们惊讶的是像这样的简单计数查询:
GOOGLE CLOUD SQL - db-n1-standard-4 (4vcpu and 15GB RAM)
1. Cold query
mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
| 3998050 |
+----------+
1 row in set (19.26 sec)
2. Repeat query
mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
| 3998050 |
+----------+
1 row in set (1.16 sec)
SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
| 10.500000000000 |
+------------------------------------------+
1 row in set (0.00 sec)
我可以多次重复查询,性能相同。 在我的 MacBook Pro 2017 上运行相同的查询,使用完全相同的转储:
MACBOOK PRO 2017
1. Cold query
mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
| 3998050 |
+----------+
1 row in set (1.51 sec)
2. Repeat query
mysql> SELECT COUNT(*) FROM `event_log`;
+----------+
| COUNT(*) |
+----------+
| 3998050 |
+----------+
1 row in set (0,51 sec)
SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
| 0.125000000000 |
+------------------------------------------+
1 row in set (0,03 sec)
更荒谬的是,正如您在上面看到的那样,我从未对默认的mysql安装进行任何调整,因此它仅在我的Macbook上使用125MB的RAM,而Google Cloud实例可用的RAM为10GB。
我们尝试将Google Cloud SQL实例大小增加到db-n1-highmen-8(8vCPU和52GB RAM!),但性能没有提高(如果我们从db-n1-standard-4降低,我们会看到性能下降)。
最后,使用这个问题,我们可以确认我们的数据库只有46GB,但在导入期间,Google Cloud SQL中的存储使用量不断增长,直到达到荒谬的74GB……我们不知道这是否是由于二进制日志记录(在Google Cloud SQL上默认启用,在我的本地机器上关闭)。
那么……有没有人在生产中使用Google Cloud sql? :)
更新:我们使用完全相同的.sql转储,并将其加载到一个db.r4.large AWS RDS中(因此具有相同的CPU / RAM),并在查询中获得了一致的0.50秒性能,并且也没有超过46GB的实例。