我有很多经验。我认为有很多不明显的问题。像 Tigase 这样运行应用程序的唯一可靠实例是 cc1.4xlarge。其他人会导致 CPU 可用性问题,这只是一个彩票,您是否有幸在不忙于其他人工作的服务器上运行您的服务。
此外,您还需要一个具有尽可能高 I/O 的实例,以确保它能够应对网络流量。高 I/O 尤其适用于数据库实例。
不确定这是否明显,但 EC2 上的主机名存在这个问题,每次启动实例时,主机名和 IP 地址都会发生变化。Tigase 集群对主机名非常敏感。有一种方法可以强制/更改实例的主机名,因此这可能是解决问题的一种方法。
当然,我说的是为数百万在线用户提供的集群,以及每秒 100k XMPP 数据包或更多的高流量。通常,对于大型安装,拥有专用服务器更便宜、更高效。
通常 Tigase 在 Amazon EC2 上运行良好,但您确实需要最新的 SVN 代码,因为它添加了许多优化,尤其是在云测试之后。如果您提供有关您的服务的更多详细信息,我可能会有更多建议。
更多评论:
如果涉及成本,专用服务器始终是持续运行服务的更便宜的选择。除非您计划每小时打开/关闭服务器,否则我建议您使用一些专门的服务。成本更低,性能更可预测。
但是,如果您真的想要/需要坚持使用 Amazon EC2,让我给您一些具体数字,下面是实例列表以及集群能够可靠处理的在线用户数量:
- 5*cc1.4xlarge - 100 万 70 万在线用户
- 1*c1.xlarge - 118k 在线用户
- 2*c1.xlarge - 127k 在线用户
- 2*m2.4xlarge(Tigase 使用 5GB RAM)- 236k 在线用户
- 2*m2.4xlarge(Tigase 使用 20GB RAM)- 315k 在线用户
- 5*m2.4xlarge(Tigase 使用 60GB RAM)- 400k 在线用户
- 5*m2.4xlarge(Tigase 使用 60GB RAM)- 312k 在线用户
- 5*m2.4xlarge(Tigase 使用 60GB RAM)- 327k 在线用户
- 5*m2.4xlarge(Tigase 使用 60GB RAM)- 280k 在线用户
还有一些评论:
- 为什么内存量这么重要?这是因为除了 cc1.4xlarge 实例之外,CPU 能力在所有实例上都非常不可靠且不一致。您有 8 个虚拟 CPU,但是如果您查看 top 命令,您经常会看到一个 CPU 正在工作,而其余的则没有。这种 CPU 能力不足会导致 Tigase 中的内部队列增长。当 CPU 恢复供电时,Tigase 可以处理等待的数据包。Tigase 拥有的内存越多,可以排队的数据包越多,它可以更好地处理 CPU 不足。
- 为什么有5*m2.4xlarge 4 倍?这是因为我在一天中的不同日期和时间多次重复测试。正如您所看到的,根据时间和日期,系统可以处理不同的负载。我猜这是因为 Tigase 实例与其他一些服务共享 CPU 能力。如果他们忙 Tigase 就会遭受 CPU 下电。
也就是说,我认为安装多达 10k 的在线用户应该没问题。但是,其他因素(例如名册规模)非常重要,因为它们会影响流量和负载。此外,如果您有其他元素会产生大量流量,这会给您的系统带来负担。
在任何情况下,如果不进行一些测试,就无法判断您的系统表现如何,或者它是否可以处理负载。
最后一个关于组件的问题:
当然 Tigase 确实支持 XEP-0114 和 XEP-0225 用于连接外部组件。所以这不应该是用不同语言编写的组件的问题。另一方面,我推荐使用 Tigase 的 API 来编写组件。它们可以部署为内部 Tigase 组件或外部组件,这对开发人员来说是透明的,您不必在开发时担心这一点。这是 API 和框架的一部分。此外,您可以使用 Tigase 框架中的所有商品、脚本功能、监控、统计,因为您可以轻松地将代码部署为测试的内部组件,因此开发更加容易。您真的不必担心任何 XMPP 特定的东西,您只需填写 processPacket(...) 方法的主体即可。
另外,我建议阅读有关 Python 对多线程的支持以及它在非常高的负载下的行为方式。它曾经不是那么好。