速救，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站点的计数器信息
所有回答(2)
0
兵来将挡，水来土掩，爬虫来缓存接，这点并发对 IIS 来说是小 case ，是你的应用扛不住，建议尝试通过缓存来解决这个问题。
如果实在想通过 IIS 进行限制，可以在 IIS 的站点设置中修改 Maximum Concurrent Connections 设置，但采取这样的限流措施后后，当达到限制值时正常请求也会被阻挡。
谢谢dudu大的回复。每次你都是第一时间回复。
你的意思是，假设我的页面只过一个 Response.Write("hello") ，几千并发不会扛不住？IIS进程池默认配置没有什么限制吗？
那我能不能理解为，我程序给出结果的速度太慢？比如被频繁抓取的一个页面“产品搜索” 功能，我使用的是lucene检索，按道理来说lucene索引也会被缓存到内存吧，我没做缓存了，如果我给它做个缓存，我还得做缓存预热吧？因为我也不知道对方提交什么关键字，他的关键字都是我不曾知道的，那我岂不是缓存不到？因为一直都命中不到啊。它不搜第二次
像博客园文章这类的缓存，我理解为，如果我想缓存，我就以文章id做为节点名，大不了再做缓存预热，也就是我自己先访问一遍，让所有文章先去了内存，这样一来不论对方访问哪个文章id都是从缓存取。
但是像产品检索这类的，我根本无法预先知道对方输入什么关键字，我做缓存预热都做不了啊。望继续赐教。谢谢。我都快要被这三波人搞疯了。
@LoveCoder: IIS 应用程序池对应的设置是 Advanced Settings 中的 Queue Lenghth
@LoveCoder: 原来是搜索场景，这个缓存发挥不了作用。并发不是来自搜索引擎的爬虫，而是来自垃圾广告爬虫，搜索页面有搜索输入框，垃圾广告爬虫以为可以通过输入框在不登录的情况下发布广告，就疯狂地发请求，即使封IP也没用，它们可以随时换 IP ，很难对付，目前我所知道的对付方法是进行人机验证，给爬虫出个验证码，一般的爬虫就立马歇菜
@dudu: emmmm，我也搞不清对方的企图，我看对方搜索的关键字也都是符合行业的，没有那种广告类的，我以前遇到过那种为了刷广告把自己的关键字顶上热搜的，后来我热搜人工干预了。这次他们来的是正常的关键字，但是就算是正常关键字，也是五花八门，我也无法预计对方会来什么关键字。
那按你的意思是，IIS进程池的设置按默认的，只要我给出结果速度够快，这个并发数也是不受限的吗？或者说IIS7.5默认配置的并发数非常非常高？
你刚说的那个 Queue Length ，调整为 65535 代表的是能并发 65535个线程还是？我刚去看，默认的是1000，这个值的含义是什么啊。看名字是"队列长度"，怎么感觉像是能进入到请求的总人数啊，但是，处理不过来，它还不是得排队吗？
@LoveCoder: 你要找出瓶颈在哪里，搜索应用消耗的是磁盘 IO 资源，如果时磁盘 IO 资源不够，其他地方再限制、优化都于事无补。
0
建议 兵来直接核弹反击。
https://blog.haschek.at/2017/how-to-defend-your-website-with-zip-bombs.html
做一个网页炸弹，遇到爬虫直接给它炸过去。
Request current 相当于qps了吧，1700已经相当恐怖了，一般的应用程序在单机部署上（除非特别简单的直接返回400，200，不做任何操作）可能撑不住，你可以自己压测一下自己的网站的最高并发量是多少。
但是目前最快，最有效果的解决方案就是dudu 说的，加上人机验证，比如极验。验证通过的给他加上cookie，这个cookie 要是加密的。
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") 都来不及做吗？请继续赐教，谢谢
首先这种不算“漏洞”的“漏洞”很多前别人已经玩剩了，这种基本上已经在代码协议中消灭了，除非特别垃圾代码，何况对方根本不需要接收，完全可以直观弄进去，收到协议开始就断开，甚至可以只管写入后就断开——你服务器还得干活。关于dudu提到限制ip，如果对方都舍得这么用，那么成本已经考虑过了，那么极验也就不再话下了。可以考虑自定义加密方式，页端去加解密，页端一定要大量使用window等内置对象——一旦这样之后，其成本将极大提升，其无法使用通用方式直接请求，如果要改写你的页端代码，需要花极大力气，如果采用浏览器模式，也必然成本陡增，效率陡降。通用的玩意儿——方便的同时，伴随更容易破解，多使用自定义才是硬道理。
