在搜索和阅读尽可能多的帖子、评论和讨论后，我发现我没有找到一个针对我的问题的特定内容。
我在同一个交付区域 us-west-2(c) 中有多个 AWS EC2 部署和一个 RDS
我正在以我很快预期的一小部分测试实例的负载。我关心的问题是推送更新时的性能。我们将频繁地一次获取 1,000 条记录的更新，并将获取和比较我们的数据，并酌情更新我们的数据。因此，每个条目一次读取和一次写入。一小时内收到 100,000 条更新并不罕见。
目前，我在 AWS t2.medium 类 RDS 上有一个 MySQL 数据库，以 22% 的 CPU 和小于 1GB 的内存运行 5 个更新进程。
即使使用这些低数字，搜索 106.3K 记录的数据库的读取时间也需要 2 到 3 整秒，而写入时间则是另外 2 秒。
我需要一些关于如何改善这些读/写时间的想法。
附加信息：我也有一个副本实例正在运行。CMS 驱动的站点（100 个并且每天都在增长）连接到副本实例以获取其内容。
谢谢！
我有两个在俄勒冈州 (us-west-2c) 运行的 EC2 实例。当我发出命令时，这些中的每一个都比我预期的要早 7 小时返回一个值。
我尝试调整时区设置，每个设置都返回一个与我预期大不相同的日期和时间。
使用 ZONE="America/Phoenix" 的值创建文件 /etc/sysconfig/clock 并没有提供任何更改。即使在重新启动实例之后。（即 sudo 重启）
我正在处理和看到的例子。（所有结果在测试时间戳后 5 分钟内。）测试时间：2016 年 3 月 26 日星期六 13:24:16 MST（美国/凤凰城）
sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/MST /etc/localtime && date
2016 年 3 月 26 日星期六 18:23:35 MST
sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/America/Phoenix /etc/localtime && date
2016 年 3 月 26 日星期六 18:24:16 MST
sudo rm /etc/localtime && sudo ln -s /usr/share/zoneinfo/GMT /etc/localtime && date
2016 年 3 月 27 日星期日 01:22:21 GMT
因此，如果 America/Phoenix 与 GMT-7 相同，则上述计算将正确。但是 America/Phoenix 关闭 7 小时是怎么回事？
亚马逊在俄勒冈州的服务器使用什么时间（区）？
谢谢。史蒂文
编辑注意：测试时间上面记错了。这已更新。- 史蒂文