可能重复：
你能帮我做一下容量规划吗？
我的团队已经创build了一个不错的Django应用程序，现在它将被部署在一个EC2实例上。 现在有几个问题，我正在寻找答案：
我知道这些问题的答案是非常主观的，大部分依赖于应用程序devise和架构。 因此，我更感兴趣的是了解做出这些决定的过程。
在问题的最后，你自己已经指出，除了“取决于”之外，不可能给你的问题提供直接的，客观的答案，所以我会尽量帮助我的（不是很大的）使用AWS的经验。
如何决定哪个实例适合我的应用（微型，小型，中型，大型等）。 换句话说，我怎么知道这个应用程序需要多less内存/处理能力？
通过testing，基准testing，实验。 这里有几篇文章指出了与其他提供商的“等效”硬件规格（ 这是一个很好的规格）相比，EC2的性能低劣。 我的build议是build立一个你最好的猜测环境，并监视，加载testing，对你的实例进行基准testing，玩弄新的实例并决定哪一个最适合你的应用程序需求。 没有你的架构的进一步的细节，这是你可能有的最好的答案。
我怎样才能量化我的服务器上的最大并发用户数。 这对于这个应用程序是非常重要的，我需要知道有多less用户会被微/小/中或大的实例支持。
同样，这在很大程度上取决于您的系统架构和交易情况。 他们是I / O密集型，CPU绑定，内存绑定？ 最好的提示是你应该试验。
我应该去安装在单个实例上的所有东西，还是应该有单独的数据库实例，备份和应用程序。
我build议你的应用程序的每一层都有独立的实例。 AWS上的典型设置包括：应用程序的EC2实例（不包括Elastic Load Balancer）（或Elastic Beanstalk），用于数据库的另一组EC2实例或RDS，用于保存文件和备份的S3 。 如果您不希望有巨大的负载（或者甚至是中等负载），那么单个medium实例可能完全适合您的需求。 分离的主要原因是你可以在未来独立地扩展它们。 这是恕我直言，AWS的最大好处：灵活性。 您可以通过点击鼠标来缩放RDS系统（几乎可以）。 您还可以在Web层之前轻松添加Elastic Load Balancer，然后将2个或3个其他Web服务器添加到您的生态系统中。 所以，我会把事情分开，以最大限度地利用这种灵活性。
我怎么能估计额外的资源需要增加每个用户（我认为这不会是线性的）
实验，基准testing等等。抱歉重复，但是当你开始部署你的资源时，你会意识到事情并不是线性的，而且在你使用AWS的时候你的期望可能并不总是这样。 通过遵循一些简单的技巧（比如我之前给出的答案），不能保证你的系统能够轻松地根据你的负载进行扩展，但是当你需要扩展的时候，事情可能不会那么痛苦。
希望能帮助到你。