摘要: 世界邦旅行網(wǎng)創(chuàng)業(yè)團(tuán)隊(北京)招聘Java工程師/PHP工程師/測試工程師/前端工程師/移動開發(fā)工程師等 閱讀全文
2011年11月21日 #
摘要: Bash 為了提高命令的解析速度,將解析過的命令的全路徑保存在hash表中,因此下次執(zhí)行的時候就無需進(jìn)行再次解析。如果在shell中修改了已經(jīng)緩存過的命令路徑,那么bash可能不能立即生效。這樣就會發(fā)生命令不能解析或者文件不存在的問題,盡管可執(zhí)行文件確實存在。 閱讀全文
摘要: OS X 下批量轉(zhuǎn)換圖片格式。 閱讀全文
摘要: Google的web字體在我朝訪問巨慢,尤其是HTTPS方式更慢,本文幫助大家解決octopress默認(rèn)的google web字體訪問太慢的問題。 閱讀全文
摘要: JRebel最新版本6.0.0的下載地址及個人學(xué)習(xí)使用版本。 閱讀全文
摘要: 本文描述如何申請2.5$每年的SSL證書,并啟用Nginx的HTTPS訪問。 閱讀全文
摘要: 線程池
并發(fā)最常見用于線程池,顯然使用線程池可以有效的提高吞吐量。
最常見、比較復(fù)雜一個場景是Web容器的線程池。Web容器使用線程池同步或者異步處理HTTP請求,同時這也可以有效的復(fù)用HTTP連接,降低資源申請的開銷。通常我們認(rèn)為HTTP請求時非常昂貴的,并且也是比較耗費資源和性能的,所以線程池在這里就扮演了非常重要的角色。
在線程池的章節(jié)中非常詳細(xì)的討論了線程池的原理和使用,同時也提到了,線程池的配置和參數(shù)對性能的影響是巨大的。不盡如此,受限于資源(機器的性能、網(wǎng)絡(luò)的帶寬等等)、依賴的服務(wù),客戶端的響應(yīng)速度等,線程池的威力也不會一直增長。達(dá)到了線程池的瓶頸后,性能和吞吐量都會大幅度降低。
一直增加機器的性能或者增大線程的個數(shù),并不一定能有效的提高吞吐量。高并發(fā)的情況下,機器的負(fù)載會大幅提升,這時候機器的穩(wěn)定性、服務(wù)的可靠性都會下降。
盡管如此,線程池依然是提高吞吐量的一個有效措施,配合合適的參數(shù)能夠有效的充分利用資源,提高資源的利用率。 閱讀全文
并發(fā)最常見用于線程池,顯然使用線程池可以有效的提高吞吐量。
最常見、比較復(fù)雜一個場景是Web容器的線程池。Web容器使用線程池同步或者異步處理HTTP請求,同時這也可以有效的復(fù)用HTTP連接,降低資源申請的開銷。通常我們認(rèn)為HTTP請求時非常昂貴的,并且也是比較耗費資源和性能的,所以線程池在這里就扮演了非常重要的角色。
在線程池的章節(jié)中非常詳細(xì)的討論了線程池的原理和使用,同時也提到了,線程池的配置和參數(shù)對性能的影響是巨大的。不盡如此,受限于資源(機器的性能、網(wǎng)絡(luò)的帶寬等等)、依賴的服務(wù),客戶端的響應(yīng)速度等,線程池的威力也不會一直增長。達(dá)到了線程池的瓶頸后,性能和吞吐量都會大幅度降低。
一直增加機器的性能或者增大線程的個數(shù),并不一定能有效的提高吞吐量。高并發(fā)的情況下,機器的負(fù)載會大幅提升,這時候機器的穩(wěn)定性、服務(wù)的可靠性都會下降。
盡管如此,線程池依然是提高吞吐量的一個有效措施,配合合適的參數(shù)能夠有效的充分利用資源,提高資源的利用率。 閱讀全文
摘要: 死鎖與活躍度
前面談了很多并發(fā)的特性和工具,但是大部分都是和鎖有關(guān)的。我們使用鎖來保證線程安全,但是這也會引起一些問題。
鎖順序死鎖(lock-ordering deadlock):多個線程試圖通過不同的順序獲得多個相同的資源,則發(fā)生的循環(huán)鎖依賴現(xiàn)象。
動態(tài)的鎖順序死鎖(Dynamic Lock Order Deadlocks):多個線程通過傳遞不同的鎖造成的鎖順序死鎖問題。
資源死鎖(Resource Deadlocks):線程間相互等待對方持有的鎖,并且誰都不會釋放自己持有的鎖發(fā)生的死鎖。也就是說當(dāng)現(xiàn)場持有和等待的目標(biāo)成為資源,就有可能發(fā)生此死鎖。這和鎖順序死鎖不一樣的地方是,競爭的資源之間并沒有嚴(yán)格先后順序,僅僅是相互依賴而已。 閱讀全文
前面談了很多并發(fā)的特性和工具,但是大部分都是和鎖有關(guān)的。我們使用鎖來保證線程安全,但是這也會引起一些問題。
鎖順序死鎖(lock-ordering deadlock):多個線程試圖通過不同的順序獲得多個相同的資源,則發(fā)生的循環(huán)鎖依賴現(xiàn)象。
動態(tài)的鎖順序死鎖(Dynamic Lock Order Deadlocks):多個線程通過傳遞不同的鎖造成的鎖順序死鎖問題。
資源死鎖(Resource Deadlocks):線程間相互等待對方持有的鎖,并且誰都不會釋放自己持有的鎖發(fā)生的死鎖。也就是說當(dāng)現(xiàn)場持有和等待的目標(biāo)成為資源,就有可能發(fā)生此死鎖。這和鎖順序死鎖不一樣的地方是,競爭的資源之間并沒有嚴(yán)格先后順序,僅僅是相互依賴而已。 閱讀全文
摘要: 剛看到這個月的編程語言排行榜,很顯然java的霸主地位很快就會在發(fā)達(dá)國家被擠掉,C語言依然是王者(想想上個月自己買的兩個C語言的書,冷汗直流)。看來我遲早要回歸C,這才是真正的王道。
非常令人吃驚的是C++語言依然不夠堅挺,由于Windows 7/Windows 8的發(fā)力,C#很快就會搶占C++的市場,估計很快就會將C++從前三名中擠下去。
iPhone/iPad的熱銷讓Object C繼續(xù)火熱,前十的位置還是可以持續(xù)很久的,這一點毋庸置疑。移動設(shè)備開發(fā)的高端人才現(xiàn)在是高薪難求,如果有時間我也要繼續(xù)關(guān)注下。 閱讀全文
非常令人吃驚的是C++語言依然不夠堅挺,由于Windows 7/Windows 8的發(fā)力,C#很快就會搶占C++的市場,估計很快就會將C++從前三名中擠下去。
iPhone/iPad的熱銷讓Object C繼續(xù)火熱,前十的位置還是可以持續(xù)很久的,這一點毋庸置疑。移動設(shè)備開發(fā)的高端人才現(xiàn)在是高薪難求,如果有時間我也要繼續(xù)關(guān)注下。 閱讀全文
摘要: Zookeeper客戶端和服務(wù)端維持一個長連接,每隔10s向服務(wù)端發(fā)送一個心跳,服務(wù)端返回客戶端一個響應(yīng)。這就是一個Session連接,擁有全局唯一的session id。Session連接通常是一直有效,如果因為網(wǎng)絡(luò)原因斷開了連接,客戶端會使用相同的session id進(jìn)行重連。由于服務(wù)端保留了session的各種狀態(tài),尤其是各種瞬時節(jié)點是否刪除依賴于session是否失效。
Session失效問題
通常客戶端主動關(guān)閉連接認(rèn)為是一次session失效。另外也有可能因為其它未知原因,例如網(wǎng)絡(luò)超時導(dǎo)致的session失效問題。在服務(wù)端看來,無法區(qū)分session失效是何種情況,一次一旦發(fā)生session失效,一定時間后就會將session持有的所有watcher以及瞬時節(jié)點刪除。
而對于Zookeeper客戶端而言,一旦發(fā)生失效不知道是否該重連,這涉及到watcher和瞬時節(jié)點問題,因此Zookeeper客戶端認(rèn)為,一旦發(fā)生了seesion失效,那么就認(rèn)為客戶端死掉了。從而所有操作都不能夠進(jìn)行。參考 How should I handle SESSION 閱讀全文
Session失效問題
通常客戶端主動關(guān)閉連接認(rèn)為是一次session失效。另外也有可能因為其它未知原因,例如網(wǎng)絡(luò)超時導(dǎo)致的session失效問題。在服務(wù)端看來,無法區(qū)分session失效是何種情況,一次一旦發(fā)生session失效,一定時間后就會將session持有的所有watcher以及瞬時節(jié)點刪除。
而對于Zookeeper客戶端而言,一旦發(fā)生失效不知道是否該重連,這涉及到watcher和瞬時節(jié)點問題,因此Zookeeper客戶端認(rèn)為,一旦發(fā)生了seesion失效,那么就認(rèn)為客戶端死掉了。從而所有操作都不能夠進(jìn)行。參考 How should I handle SESSION 閱讀全文
摘要: 為了提高性能,最近將Redis從2.2.x的最新版2.2.12升級到2.4.x(2.4.2),驚喜的發(fā)現(xiàn)內(nèi)存占用節(jié)省了很多。大贊!
有人說Redis的作者是一個勤奮的人,深表同意!
本來升級是為了增加批量操作從而提高性能,沒想到內(nèi)存占用節(jié)省了很多。
對于32位的操作系統(tǒng)而言,節(jié)省內(nèi)存62%,對于64位操作系統(tǒng)而言節(jié)省73%。非常可觀。 閱讀全文
有人說Redis的作者是一個勤奮的人,深表同意!
本來升級是為了增加批量操作從而提高性能,沒想到內(nèi)存占用節(jié)省了很多。
對于32位的操作系統(tǒng)而言,節(jié)省內(nèi)存62%,對于64位操作系統(tǒng)而言節(jié)省73%。非常可觀。 閱讀全文