如何parsing服务器的性能

我有一个应用程序，可以看到来自世界各地的使用情况，大部分在欧盟。 但是，由于我们正在进行服务器移动/体系结构更改，我希望听到社区对以下情况的意见，以便找出哪些方法最适合用于向前移动。

我们使用Parse作为我们唯一的API端点，目前在Elastic Beanstalk上运行，这使我们能够相对快速地创build新的区域。 但是，每个parsing服务器与之通信的MongoDB都位于AWS爱尔兰。 考虑到复制这些数据既昂贵又复杂，我设想我们在一个地区有一个MongoDB，好一段时间。 由于这个限制，我一直在考虑以下两种情况 – 附有粗糙的图片。

这两种情况都涉及用户对Parse服务器和与MongoDB集群进行通信的分析服务器进行API调用。

1.分布式服务器。 这个想法有一个小的AWS服务器运行尽可能靠近用户，服务器将执行长距离回到数据库。 考虑一下澳大利亚的用户在悉尼的一台服务器上，以及在爱尔兰拨打数据库的AWS基础设施。

• BMC – 待机或关机时的IPMI电源使用情况
• 将AWS CloudFormation模板部署到多个区域时，如何防止出现重复的DNS条目错误？
• 我用cloudformation来创buildWordPress的博客，但域没有正确显示
• 如何在AWS中为在Route53中托pipe的域授予交叉授予权限？
• 如果hostedzone包含不需要的logging，CloudFormation将无法删除堆栈，如何避免？

• 我预计AWS服务器 – AWS服务器将比选项2更快？

2.中央服务器（靠近Mongo群集）。 这个选项有服务器，有可能是内存较大，CPU放在与DB相同的区域意味着Server-Database之间的快速通信。 考虑到同一个澳大利亚用户; 他们将到达欧盟打Parse Server，它将执行数据库查找并将数据返回给Aus。

• 我预计这会比较慢，因为用户的路线可能比AWS-AWS慢。

分布式服务器在实践中我应该去select1（我会等待听到的回应）我预计执行以下，我很有兴趣听到你的想法：

• 分别在爱尔兰AWS t2.micro的世界范围内连接到全世界所有连接到MongoDB集群的3-4台t2.micro服务器。
• 使用Route 53 GUI在Latency和Server运行状况下创build场景映射路由stream量，以便在服务器崩溃时提供一些冗余。
• 将我的域名的CNAME指向负载平衡器的AWS URL / IP（我不确定这一点 – 您点击了什么端点以便AWS执行路由，它是负载平衡器吗？

希望这对你们中的一些人来说是有意义的，他们可能会提供一些build议。

非常感谢。