首页新闻找找看学习计划

速救,IIS7.5如何提高并发量?

1
[待解决问题]

最近不知道为什么,iis 日志里面多了几个奇怪的蜘蛛,其一是 +Bytespider ,据说是字节跳动做站外搜索的蜘蛛,我真相问候字节跳动的开发,你们的蜘蛛都不用控制频率的吗?我都搞不懂你们是怎么并发的,我一个分页展示产品的分类浏览页面,它愣是一口气并发出了几百个请求,同时请求几百页。。。。。这样子并发我不做缓存预热都没法防吧。后来我果断的直接把这个蜘蛛的user-agent给屏了,检测到这个ua的直接给404了

不过还有两家蜘蛛,并发量不像这个,但是也能搞死我的服务器,我的windows 服务器的计数器上,并发高到一两千的时候,网站就很卡,几乎无法运行,好像是有队列被挂起?
主要是 Request current和Request Queued 飙升(这是我从别人的帖子里面学来的说是看这个),大概数值是 1700的样子,网站就奇卡了。
我的web服务器,配置是 E5-2680 4核的 16g内存的 ,每个站点用了一个独立的IIS进程池,IIS进程池我没有做特殊的配置,就是创建一个IIS进程池后,直接拿来用的。IIS版本是 7.5,windows server版本是 server 2008
我现在想知道的问题是:
一、我这样配置IIS进程池,能支持的最高并发数是如何计算的?
二、我该如何修改配置,才能使得改站点支持的并发数提高?
三、假设我某个aspx页面只 Response.write("hello") ,哪怕是这么一个简单的页面,也有最高并发数限制吗?这个问题和第一个问题其实是一个问题吧,我想表达的意思是,哪怕我这个页面再简单,也会受到并发数限制吗?因为我给这个被频繁抓取的页面加了一个算法,记录每个IP,发现这个IP一分钟内访问次数超过xx次后,就直接给对方response.write 了一段文字(我记录IP一分钟内访问次数是记在内存缓存,以" IP_时分秒"作为缓存节点,所以写入和判断应该是非常快的。),所以哪怕是这么一个简单的判断+response.writer 也是受到最高并发数限制的吗?
下图是我的IIS站点的计数器信息

IIS
LoveCoder的主页 LoveCoder | 初学一级 | 园豆:7
提问于:2019-09-01 12:51
< >
分享
所有回答(2)
0

兵来将挡,水来土掩,爬虫来缓存接,这点并发对 IIS 来说是小 case ,是你的应用扛不住,建议尝试通过缓存来解决这个问题。

如果实在想通过 IIS 进行限制,可以在 IIS 的站点设置中修改 Maximum Concurrent Connections 设置,但采取这样的限流措施后后,当达到限制值时正常请求也会被阻挡。

dudu | 园豆:41011 (高人七级) | 2019-09-01 13:20

谢谢dudu大的回复。每次你都是第一时间回复。

你的意思是,假设我的页面只过一个 Response.Write("hello") ,几千并发不会扛不住?IIS进程池默认配置没有什么限制吗?

那我能不能理解为,我程序给出结果的速度太慢?比如被频繁抓取的一个页面“产品搜索” 功能,我使用的是lucene检索,按道理来说lucene索引也会被缓存到内存吧,我没做缓存了,如果我给它做个缓存,我还得做缓存预热吧?因为我也不知道对方提交什么关键字,他的关键字都是我不曾知道的,那我岂不是缓存不到?因为一直都命中不到啊。它不搜第二次

支持(0) 反对(0) LoveCoder | 园豆:7 (初学一级) | 2019-09-01 13:31

像博客园文章这类的缓存,我理解为,如果我想缓存,我就以文章id做为节点名,大不了再做缓存预热,也就是我自己先访问一遍,让所有文章先去了内存,这样一来不论对方访问哪个文章id都是从缓存取。
但是像产品检索这类的,我根本无法预先知道对方输入什么关键字,我做缓存预热都做不了啊。望继续赐教。谢谢。我都快要被这三波人搞疯了。

支持(0) 反对(0) LoveCoder | 园豆:7 (初学一级) | 2019-09-01 13:34

@LoveCoder: IIS 应用程序池对应的设置是 Advanced Settings 中的 Queue Lenghth

支持(0) 反对(0) dudu | 园豆:41011 (高人七级) | 2019-09-01 13:47

@LoveCoder: 原来是搜索场景,这个缓存发挥不了作用。并发不是来自搜索引擎的爬虫,而是来自垃圾广告爬虫,搜索页面有搜索输入框,垃圾广告爬虫以为可以通过输入框在不登录的情况下发布广告,就疯狂地发请求,即使封IP也没用,它们可以随时换 IP ,很难对付,目前我所知道的对付方法是进行人机验证,给爬虫出个验证码,一般的爬虫就立马歇菜

支持(0) 反对(0) dudu | 园豆:41011 (高人七级) | 2019-09-01 13:53

@dudu: emmmm,我也搞不清对方的企图,我看对方搜索的关键字也都是符合行业的,没有那种广告类的,我以前遇到过那种为了刷广告把自己的关键字顶上热搜的,后来我热搜人工干预了。这次他们来的是正常的关键字,但是就算是正常关键字,也是五花八门,我也无法预计对方会来什么关键字。

那按你的意思是,IIS进程池的设置按默认的,只要我给出结果速度够快,这个并发数也是不受限的吗?或者说IIS7.5默认配置的并发数非常非常高?
你刚说的那个 Queue Length ,调整为 65535 代表的是能并发 65535个线程还是?我刚去看,默认的是1000,这个值的含义是什么啊。看名字是"队列长度",怎么感觉像是能进入到请求的总人数啊,但是,处理不过来,它还不是得排队吗?

支持(0) 反对(0) LoveCoder | 园豆:7 (初学一级) | 2019-09-01 13:58

@LoveCoder: 你要找出瓶颈在哪里,搜索应用消耗的是磁盘 IO 资源,如果时磁盘 IO 资源不够,其他地方再限制、优化都于事无补。

支持(0) 反对(0) dudu | 园豆:41011 (高人七级) | 2019-09-01 14:01
0

建议 兵来直接核弹反击。

https://blog.haschek.at/2017/how-to-defend-your-website-with-zip-bombs.html

做一个网页炸弹,遇到爬虫直接给它炸过去。

Request current 相当于qps了吧,1700已经相当恐怖了,一般的应用程序在单机部署上(除非特别简单的直接返回400,200,不做任何操作)可能撑不住,你可以自己压测一下自己的网站的最高并发量是多少。

但是目前最快,最有效果的解决方案就是dudu 说的,加上人机验证,比如极验。验证通过的给他加上cookie,这个cookie 要是加密的。

Shendu.CC | 园豆:1771 (小虾三级) | 2019-09-01 14:04

Request current 我是从网络上搜索出来,然后按那个人说的添加了计数器,
一共有两个指数,一个是 Request current ,一个是 Request Queued ,我看了一下正常情况下 Request current只有几十,一般50上下, Request Queued 是0。按那个人的说法是现在队列里面没有排队的,然后那种恶心的蜘蛛一来, Request current 瞬间就爆发到 1700甚至2600,然后 Request Queued 也跟着一起差不多的数值,可能就是超过了一定值我就处理不了,就开始排队了,所以,我想知道这个 Request current 到底是什么?按翻译字面上意思是 当前请求数量 吗?也就是这一刻瞬间有这么多个请求同时到达,换句话说,大概就是程序要开辟这么多线程去处理这些请求吗?然后因为我服务器性能不行,导致不能瞬间开辟这么多线程出来去处理,所以就到队列里面去等待处理了吗?
如果按你的说法,1700的 Request current ,我网页甚至连response.write("hello") 都来不及做吗?请继续赐教,谢谢

支持(0) 反对(0) LoveCoder | 园豆:7 (初学一级) | 2019-09-01 18:43

首先这种不算“漏洞”的“漏洞”很多前别人已经玩剩了,这种基本上已经在代码协议中消灭了,除非特别垃圾代码,何况对方根本不需要接收,完全可以直观弄进去,收到协议开始就断开,甚至可以只管写入后就断开——你服务器还得干活。关于dudu提到限制ip,如果对方都舍得这么用,那么成本已经考虑过了,那么极验也就不再话下了。可以考虑自定义加密方式,页端去加解密,页端一定要大量使用window等内置对象——一旦这样之后,其成本将极大提升,其无法使用通用方式直接请求,如果要改写你的页端代码,需要花极大力气,如果采用浏览器模式,也必然成本陡增,效率陡降。通用的玩意儿——方便的同时,伴随更容易破解,多使用自定义才是硬道理。

支持(0) 反对(0) 花飘水流兮 | 园豆:10339 (专家六级) | 2019-09-02 15:29
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册