一次面試引起的思考(中小型網站優化思考)

前言

　　故事的原由是這樣的，因爲本人地處偏僻工做地點在美麗的冰城哈爾濱雖然地方很美麗，可是這裏的軟件行業實在是算不上「美麗」，這麼多年因爲我的緣由或者公司緣由常常換工做，由於這裏都是中小型公司，沒有什麼大公司。今天安靜的上班明天老闆接不到外包可能就要解散，我見過最狠的老闆壓了我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建模都沒學過，這樣給團隊協做開發形成了很是大的影響，也給一些公司形成了不可挽回的損失，有一些老闆一直在催快點幹完，這個項目三天，三天能不能完成？他們只注重速度和錢，可是不注重質量，像我面試的這個公司同樣本身開發的系統，竟然還一直崩潰，一個網站或者公司，雖然開始的定位必定是中小型，可是咱們避免不了要發展要生存，這還只是一個公司內部的系統，若是要是線上的項目，我估計沒準連服務器都會崩潰了! 雖然幹了五年由於不是專業出身因此底子很差寫的也不怎麼樣，但願各位朋友能指點指點我，這只是我人生路上面試過程當中的一個小部分，我只想說，不管咱們是作程序員仍是作人，要對得起本身的技術，對得起本身的研究成果！作到心安理得就能夠了！