谢谢你们，任何想法/见解都会受到赞赏，因为这使我疯狂。
问题：在应用程序停止之前，只有大约3或4个用户可以同时使用服务器。
目前我们看到正常使用情况下CPU使用率的巨大峰值。 与真实用户相比，这比使用自动化脚本更容易复制，原因不明，但是脚本可能无法很好地模拟真实的使用情况。
我们的架构如下：
- 应用程序服务器（Tornado） – 单线程，具有asynchronousIO循环。 我们使用Tornado处理与长轮询相关的持久连接，并通过WSGI将所有基本的Web请求发送给Django。
- Django ORM用于与数据库交互，尽pipe大多数SQL是手工编码的
- MySQL数据库
- Nginx提供静态媒体并将其他请求代理给Tornado
- 目前所有东西都安装在一个“Small”EC2实例上运行。 在机器之间分离服务器对性能没有明显的影响
有关服务器configuration的更多详细信息，请参阅EC2服务器规范： http ： //aws.amazon.com/ec2/instance-types/ 。 注意：总而言之，这不是理想的和最可伸缩的设置，但它应该能够处理3个以上的用户！
运行顶部和查看日志显示以下内容：
- CPU峰值大部分归功于Tornado，每个活跃用户大约有25％的CPU使用率
- 低的“偷窃时间”，所以我们的CPU能力不会被EC2严重扼杀（再次）
- 数据库查询全部在0-200毫秒之间，当CPU没有峰值时，通常在峰值期间持续3秒或更长时间
- 内存使用率低，从不出现高峰
有些事情已经试图无济于事：
- configurationMySQL缓冲区大小，索引等。 我99％肯定这不是一个花园式的SQL /数据库优化问题
- 改善查询时间并以各种方式减less查询次数
- 将服务器放在单独的ec2实例上
- 多个应用程序服务器之间的代理（这显然是更大的可扩展性，但它不能解决每用户3个用户的问题）
- 升级EC2实例。 从“微”升级确实有帮助（由于CPU节stream问题），但只是稍微增加了我们的容量
- 部署在非EC2服务器（Slicehost）上 – 同样的问题
- 所有服务器都通过简单的testing用例单独进行了负载testing，并且都能够处理1000个同时连接
“龙卷风，每个活跃用户额外的CPU使用量约25％” – 如果每个用户咀嚼25％的核心，单线程应用程序只会在应用饱和之前达到4个用户只有它能够使用的核心。 弄清楚为什么龙卷风是一个如此荒谬的CPU猪（你的代码是坏的，还是龙卷风不好？），你的解决scheme将跌出谷底。