前言：
标题为啥要加个“小”，只因为上一篇文章“小网站架构优化：从100并发抗到4000并发”，带了个“小”字，所以这篇也顺流加个“小”了。
大意“小”是特指秋色园（流量小，服务器配置低）的意思，毕竟文章都是从实战后才写出来的。
关于现实网站的抗并发实情：
由于每个网站的性能点，最后都离不开抗并发这一话题。
也许，网站本身并没有那么多并发访问，但为何还要抗并发？
因为现实不是每个人都是善良的，商业竞争也很激烈，竞争对手间时不时的互相攻击网站也很普遍。
昨天才一网友向我说起，他朋友的网站，逢周一就会被竞争对手攻击，导致业务无法开展，换服务器也无济于事。
所以，提升网站的抗并发能力，除了抵抗用户的高峰期访问，也是是自我网站保护的一种手段。
什么样的站点能抗的起高并发？
若除却外部带宽等因素造成的外部影响，则内部答案只有一个：静态网站。
静态网站何以能抗高并发？
因为静态页面据说在操作系统内核级就能缓存数据并做出响应，所以抗并发能力理论上是最强的。
所以，你看看电商网站，除却技术背后的实现，你能看到的页面，多数是静态页面。
所以技术的背后是Java还是.net还是php，看似就不是那么的特别了。
当然了，也不是所有站点都适合静态化，所以技术架构优化显的特别的重要。
根据某网友提供的数据，仅供参考：
CSDN首页的文章：2000并发以下挂了，这块是java提供服务。
而CSDN的博客：能顶好万级的并发，这块是ASP.NET提供服务。
而CSDN的论坛：能顶好几十级以上的并发，这就是静态化的结果。
所以那篇很火的“去.NET化的文章”，可能是作者个人意淫，当然了，这些数据可能也是意淫的结果，不一定所属事实。
所以，要提高抗并发数，高配的服务器不是全部，还需要合理的代码架构优化：
本次实践分离方案的背景：
在秋色园系统的优化文章中，都似多似少的提到了搜索这块引发的CPU命案。
某天，我想起了“IIs 网站应用程序与虚拟目录的区别及高级应用说明”这篇文章的内容。
有了想把搜索独立出去的想法，这样即使搜索挂了，也不影响网站访问，更不用担心搜索引发的CPU命案。
构思中：
于是三七二十七，就开始想了：
目前秋色园的URL搜索这一块为：www.cyqdata.com/search/类型/搜索内容。
而文章的关键字（一般博客为设置为tag，引到文章，而我是引到搜索区）。
想了两种方案：
A：是弄个二级域名，建个网站来运行，这个需要动点代码：
这种方案，要修改URL变为so.cyqdata.com/类型/搜索内容，看似改动不少，需要调整URL机制和301处理，预计整体在30-60分钟内应该可以解决完。
这种方案的好处是，后续扩展可以部署到其它服务器。
这种方案的好处是，后续扩展可以部署到其它服务器。
B：直接使用子应用程序，可以不改动代码，直接把搜索这块分离独立子应用程序运行：
这种方案，代码不用改，因为根据search建立子应用程序即可。
这种方案，一般就局域服务器只能在局域网内了。
这种方案，一般就局域服务器只能在局域网内了。
方案选择：
综合秋色园目前的情况，也就一台VPS。
两个方案的区别就在于动代码和不动代码了。
后来我选择了不动代码，因为实际的效果几乎是一样的，所以就不动代码了。
方案二实施过程：
1：在IIS 6 里新建一虚拟目录search，创建右键属性，应用程序名那里对应的按钮点击“创建应用程序”然后虚拟目录就转化为应用程序了。
2：项目路径还是原来的项目路径，然后设置新的应用程序池，最终如下图：
总结：
一般一个项目大了后，或者逻辑变的复杂后，往往的解决方案就是分解成子项目。
而分解的方案：一般是根据域名，或首页节点目录。
后来思绪了一下，比如目前博客的URL是：xxx.com/cyq1162/admin/...
如果一开始考虑把它设计成：xxx.com/admin/cyq1162/...
这样是不是也就可以轻松的把博客的前后台分离开来。
当然了，分成多个进程，是需要思考，是否有涉及直接的通讯。
文本就介绍到这里了，仅提供一种参考方案。
版权声明：本文原创发表于博客园，作者为路过秋天，原文链接：
http://www.cnblogs.com/cyq1162/archive/2013/05/27/3101834.html