设置：EC2服务器在ELB后面自动扩展,连接到RDS mysql数据库,从cloudfront提供的所有静态文件.
我正在运行Nginx作为EC2服务器上的Web服务器,keepalive设置为20,工作进程4 ,. Codeigniter是后端并使用codeigniter会话.
我一直在运行许多基准试图测试性能,围攻,apache基准,blitz.io.
我正在测试两个特定页面,第一个性能非常好,它使用codeigniter会话,因此命中数据库以读取和更新ci_sessions数据库.第二页是我遇到问题的页面,它运行一个带有多个连接的查询,这些连接在一个用户的大约0.4秒内完成.此查询已优化,我正在使用InnoDB表.在带有c10和n1000的apache基准测试下,100％的请求在634毫秒内返回.
当我运行并发用户时> 200我开始遇到问题.添加更多的EC2服务器没有帮助,cpu的利用率约为50％. RDS数据库监视还显示cpu和内存使用率小于70％,并且平均DB连接小于70％. 35.
通过迁移到大型RDS实例和大型EC2实例,性能得到了提升,这让我想知道I / O是否会在这里发挥作用.
如果我在负载测试期间启动ELB外部的服务器并点击此页面,它会在不到一秒的时间内返回,但如果我启动ELB中的另一台服务器,它将保持最多4或5秒.这表明我没有超载RDS.
我尝试用5分钟的爆发缓慢升高ELB,这似乎没有帮助.
我想知道下一步该问题,无论是某种I / O问题还是其他问题,因为RDS和EC2服务器似乎没有被推到他们的能力.任何有关下一步的建议或想法都将非常感激
解决方法:
> ELB通常不太擅长突发缩放.在与亚马逊工程师讨论此事后,我发现他们实际上不会在爆发时扩展ELB,因为这是不可能的.随着时间的推移,您需要保持一致的负载才能使ELB按比例放大.因此,我改用haproxy.除了ELB不能在突发负载上进行缩放之外,它还使用CNAME进行DNS查找,这也将影响您的性能.因此,如果您计划经常出现突发负载,或者要求进行DNS查找,那么最好是从ELB下来.
> RDS是一个黑盒子.嗯,这不完全正确,但总的来说,我避免使用RDS,除非我知道后端是一个易于扩展的简单设置.话虽如此,RDS确实有助于扩展,但我会愚蠢的后端并确保您的查询快速运行.在常规MySQL实例上运行它,看它是否是亚秒级.根据我的经验,当你说查询是“优化的”时,并不意味着没有其他方法可以让它更加“优化”,如果你抓住我的漂移.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
