前言
故事的起因是这样的，由于本人地处偏僻工作地点在美丽的冰城哈尔滨虽然地方很美丽，但是这里的软件行业实在是算不上“美丽”，这么多年由于个人原因或者公司原因经常换工作，因为这里都是中小型公司，没有什么大公司。今天安静的上班明天老板接不到外包可能就要解散，我见过最狠的老板压了我6个月的工资，我都忘记我当年为什么没被饿死过来的，据说年前有一个哈尔滨的某奇葩食品行业公司雇佣了好几十个员工干活，结果项目做完了以后，公司申请破产了，末月就是不给你结算，爱那那告，结果几个月以后又开始恢复营业了。(好吧我的嘴癌又开始犯了)言归正传，由于这种环境所以我对自己的技术也有一个了解，高难度项目不好说，但是一些中小型的解决方案，即使拿不下，也能说个六七分。今年大概三月份开始陆陆续续面试了一些公司(因为工资要的多，所以很多时候要仔细甄选是不是骗子，不能给个电话就去。) 有一天我面试了一家据说很大，给百度旗下做seo优化的公司，全国有五个分部。
概况
面试的过程很简单一个年纪跟我差不多的兄弟出来大概问了我几个问题,问了问工作年限，我说我是12年毕业的，虽然是12年毕业但是实际我已经工作五年了，他停顿了一会，然后跟我聊了聊雇佣人的原因：
据说他们公司花了很久的功夫开发了一套系统，这个东西就是处理集团五个分部的业务和会计实务进行报告的总公司,进行递交，然后进行月末统计，但是问题来了因为月末要提交所以五个分部总是在月末的最后一天递交相关资料,结果系统老是崩溃，他们想招收一个能解决问题的大拿，但是说的过程我就看出来可能觉得我很年轻，语气很是轻蔑，我当时就有预感肯定不会要我，但是我稳住了，可是我心里也很是轻蔑，花了好几年做的一套系统，一直崩溃，你们以前的技术经理是吃s的？但是，为了保持矜持(不要打我)，我就岔开了话题问了一点别的，为了不引起疑心，我旁敲侧击的问了一下集团情况,他说咱们总部是150人,我说那外面呢？他说都差不多,这个时候我的脑洞的打开了,假如咱们取个中间值,五个分部,每个分部160人,那么就是800人，一个综合性公司,开发人员不能上传报表吧？销售也是,他也说了,只是管理会计这一块的,我们取个中间值,上下的并发量400人的网站,（我觉得差不多了,其实如果网站规划得好400的并发和800的并发优化没什么区别）一个网站400就崩了,我觉得好可怜，（为什么他们还那么趾高气昂？），然后我又问咱们用的是几台服务器？他说是一台，最后他说您想要多少钱的工资？我说8k-10k,结果他马上站起来就说：你可以走了! 就凭借这句话我再也不想来这个公司面试了。
分析
我问的问题可能不全面但是是有条理的,我问他们几台服务器,就是想问问做没做基本的图片服务器和数据库服务器分离,结果是就这样被征服了。
那么问题就来了，原因可能是如下几种：
1.上传的文件太多(或者图片太多)。
2.网页的页面压力太大写的不够好。
3.数据库的压力太大。
思路
第一种问题解决方案，上传的文件太多,这个问题最难解决了,同时也是最简单的,因为解决的方案就是一个字钱，君不见优酷土豆此类网站烧钱之甚啊！因为涉及到并发,打个比方,一条高速公路是100M，那么你的并行量级咱们就按照100M计算，(这种说法已经最笨了)假设每个人的上传5M的文件和图片那么这个网站的并发我是不是就可以认为是100/5 = 20呢？ 也就是说这个网站只能20个人访问了，多了轻则卡顿丢失文件,总则就是网站崩溃了,这种问题也最难解决,因为文件和图片永远都是网站流量的最大杀手,没什么好办法只能做图片服务器分离.文件服务器分离了,(但是这里又违背了人家只用一台服务器的原则),有的公司看上去很大,但是老板就是对IT部门不重视不投资那么多没什么办法。
第二种问题解决方案，网页的页面压力太大不够好，这个我可要说说了，我见过很多程序员写的页面一直都是在应付，因为我是做.net开发的，虽然.net的定位一直都是中小型网站，但是我认为不能因为它只是个中小型网站就可以敏捷开发一样快速写成功了没有了bug就可以了，咱们具体分析一下原因：
IIS 内部运行机制及Asp.Net执行过程详解 中说道：(咱们就根据iis5.x的运行机制来分析一下)
当一个HTTP请求从客户端发送过来之后会被WEB服务器进行Queue并进行分解归类，如果某个请求仅包含静态文件的请求，比如CSS,JS,Html文件或者虚拟目录所包含的文件如图片，IIS直接提取对应的文件将其作为Http Response返回给Client，如果事情仅仅是这样，我们很多人就会失业了,呵呵。但是对于这些需要进一步处理的动态执行的文件，IIS必须将Request进一步传递给对应的处理程序，待处理程序执行完毕获得最终的Http Response通过IIS返回给Client。如果一个请求中包含动静态请求，那么静态内容会等到动态内容生成HTML后组合在一起返回给Client。对于IIS来说，这些处理程序通过ISAPI Extension来体现。ISAPI Extension接收到请求页的扩展名之后会到IIS的Metadata database维护着一个称为ISAPI Extension Mapping的数据表查询，负责将不同类型的Resource影射到对应的ISAPI Extension。对应.ASPX的Mapping是ASP.NET ISAPI,至此，ASP.NET ISAPI会创建一aspnet_wp.exe的worker process(若该Process不存在的话)。当地一个ASP.NET接收到Application中的任何一个.ASPX请求时，名为ApplicationManager的类会创建一个ApplicationDomain(应用程序域)。ApplicationDomain会为全局变量提供应用程序隔离，并允许单独写真每个应用程序。在应用程序域中，将为名为 HostingEnvironment 的类创建一个实例，该实例提供对有关应用程序的信息（如存储该应用程序的文件夹的名称）的访问。如果需要，ASP.NET 还可对应用程序中的顶级项进行编译，其中包括 App_Code 文件夹中的应用程序代码。创建了应用程序域并对 HostingEnvironment 对象进行了实例化之后，ASP.NET 将创建并初始化核心对象，如 HttpContext、HttpRequest 和 HttpResponse。 HttpContext 类包含特定于当前应用程序请求的对象，如 HttpRequest 和 HttpResponse 对象。 HttpRequest 对象包含有关当前请求的信息，包括 Cookie 和浏览器信息。 HttpResponse 对象包含发送到客户端的响应，包括所有呈现的输出和 Cookie。
从上面的分析我们可以总结出iis读取页面的机理和原因：
第一种:就是对internet请求进行分析和归类,分成静态页面请求和动态页面请求,所谓的静态请求就是html静态页面，动态请求我们暂时理解为aspx，或者cshtml请求。
第二种:就是对动态页面请求进行分析，等到动态请求分析成为静态请求的时候组合再一起返回给浏览器。
所以我得出了两个结论:
第一种，我们把一些流量高但是页面数据不总是变化页面我们可以考虑使其静态化。这也是现在一些流行网站的做法。
第二种，我们可以尽力的减少动态请求分析的时间。
第三种数据库压力大的解决方案,这种问题很多就是程序员自己自身素质的问题了,或者架构没有搭建好。
我猜想原因可能是:
第一种，有的人喜欢把文件或者图片变成二进制保存到数据库里，这样参照第一种崩溃原因。
第二种，就是有的程序员他很擅长数据库方面的技术,所以他把所有的业务和逻辑都封装成了存储过程保存在数据库里，后台代码只有一个事务回滚甚至没有，这样的业务，在后台响应时间内接收不到回应自然会报错了。
结尾
我想说的是，.net语言因为其入门门槛低，容易掌握，造成了很多程序员素质参差不齐，也有很多程序员学了很多年坐了项目经理连最基本的uml建模都没学过，这样给团队协作开发造成了非常大的影响，也给一些公司造成了不可挽回的损失，有一些老板一直在催快点干完，这个项目三天，三天能不能完成？他们只注重速度和钱，但是不注重质量，像我面试的这个公司一样自己开发的系统，居然还一直崩溃，一个网站或者公司，虽然开始的定位一定是中小型，但是我们避免不了要发展要生存，这还只是一个公司内部的系统，如果要是线上的项目，我估计没准连服务器都会崩溃了! 虽然干了五年因为不是专业出身所以底子不好写的也不怎么样，希望各位朋友能指点指点我，这只是我人生路上面试过程中的一个小部分，我只想说，无论我们是做程序员还是做人，要对得起自己的技术，对得起自己的研究成果！做到问心无愧就可以了！