前言
故事的起因是這樣的，由於本人地處偏僻工作地點在美麗的冰城哈爾濱雖然地方很美麗，但是這裡的軟件行業實在是算不上美麗，這麼多年由於個人原因或者公司原因經常換工作，因為這裡都是中小型公司，沒有什麼大公司。
今天安靜的上班明天老板接不到外包可能就要解散，我見過最狠的老板壓瞭我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 建模都沒學過，這樣給團隊協作開發造成瞭非常大的影響，也給一些公司造成瞭不可挽回的損失，有一些老板一直在催快點幹完，這個項目三天，三天能不能完成？他們隻註重速度和錢，但是不註重質量，像我面試的這個公司一樣自己開發的系統，居然還一直崩潰，一個網站或者公司，雖然開始的定位一定是中小型，但是我們避免不瞭要發展要生存，這還隻是一個公司內部的系統，如果要是線上的項目，我估計沒準連服務器都會崩潰瞭！ 雖然幹瞭五年因為不是專業出身所以底子不好寫的也不怎麼樣，希望各位朋友能指點指點我，這隻是我人生路上面試過程中的一個小部分，我隻想說，無論我們是做程序員還是做人，要對得起自己的技術，對得起自己的研究成果！做到問心無愧就可以瞭！