我是一个开发操作web开发人员,在AWS上的负载均衡器后面运行两个ec2.smalls的站点。
最近我们看到每秒3-4次请求将我们的客户网站删除。
该站点已经关闭,并且在多台服务器重新启动和错误日志扫描可能导致问题的任何脚本后不会返回,即使最近没有更改。
在打开负载均衡器日志之后,我看到来自一个IP地址的1000 s对单个页面的请求。
我们将负载均衡器的请求转发到使用X转发的服务器处理请求,并使用.htaccess规则阻止IP。
在与客户( IT )通信时,他们被告知负责大量请求的IP地址实际上是他们的内部公司机器之一。
负责的机器被远程重启,所有请求都停止了。该网站重新上线。
官方对此的解释是“电脑吓坏了”。
web浏览器或windows机器是否有可能每秒向负载平衡的网页发出3-4次请求,并将其降至5+小时?
以下是请求的样子:
2017-01-14T01:00:46.170447Z west-ssl XX.XXX.XX.XXX:33370 - -1 -1 -1 503 0 0 0 "GET https://www.example.com:443/example/12 HTTP/1.1" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" ECDHE-RSA-AES128-SHA256 TLSv1.2发布于 2017-01-17 19:10:35
当然,这是可能的--尽管这取决于许多因素:
1)听起来服务器端应用程序存在并发问题。如果是应用程序服务器成为瓶颈,或者它是上游的,比如DB和应用程序服务器由于apache配置没有足够快地刷新线程而耗尽内存,可能值得一看。如果是应用服务器,那么可能值得进行一些调优--在ELB之外配置一台相同的机器,并使用JMeter向其抛出一些负载,以找出瓶颈。
如果是数据库,则可以使用memcache/elasticache (因为它看起来像是要检索特定的对象)来缓存实际的查询。通过这种方式,db连接可以快速响应,Apache可以快速响应,并关闭线程,而不是填满应用程序机器的内存池。
如果您真的感到脆弱,您可以将Varnish放在上游,将请求缓存在1-5s的TTL中,以防止重大请求泛滥。但是要小心,因为VCL是不可饶恕的,可能导致重大问题和痛苦(缓存中毒/泄漏)。
2)至于“主体”机器本身。很明显它可能被破坏了-它绝对应该被调查。我将让您决定IT人员是否诚实--这超出了服务器错误的范围。
假设它没有被破坏,它可能是一些糟糕的javascript代码--如果您执行轮询刷新并以某种方式修改了一个定时参数,它很可能开始每秒发送许多请求。类似地,JS可能表现良好,但是这个人可能打开了25个选项卡,晚上回家了--如果每个人每5秒发送一个请求,那就是5req/秒。
https://serverfault.com/questions/826846
复制相似问题