大型高性能網(wǎng)站的十項(xiàng)規(guī)則(文件)
【正文】 的Syslog。這樣出現(xiàn)問題的時(shí)候，查看主要的系統(tǒng)日志就可以很容易地看到發(fā)生了什么。這使得我們可以記錄非常詳細(xì)和強(qiáng)大的日志，用來分析和調(diào)試在生產(chǎn)操作中所發(fā)生的問 題。這樣的SQL代碼在開發(fā)環(huán)境中可能運(yùn)行很快，因?yàn)槠渲兄挥行?shù)據(jù)集和最小的負(fù)載。這并不重要，我們關(guān)注的是在系統(tǒng)增大并遇到性能問題之前找到這些問題并加以解決。在主配置文件中，INNODB應(yīng)該被設(shè)置為默認(rèn)的數(shù)據(jù)庫引擎，并且系統(tǒng)應(yīng)該不時(shí)地進(jìn)行檢查，看是否意外創(chuàng)建了MyISAM的表。另外還要確保擁有設(shè)計(jì)合理的MySQL配置?！ ?. 使用讀/寫數(shù)據(jù)庫分離 隨著系統(tǒng)變得越來越龐大，特別是當(dāng)它們擁有很差的SQL時(shí)，一臺(tái)數(shù)據(jù)庫服務(wù)器通常不足以處理負(fù)載。因此，即便在開始時(shí)使用同一臺(tái)數(shù)據(jù)庫服務(wù)器，也要盡早計(jì)劃在PHP中使用分離的DB連接來進(jìn)行讀寫操作。但是要小心的是，不要100%依賴于一臺(tái)Memcache服務(wù)器來提高性能，因?yàn)槿绻桥_(tái)服務(wù)器崩潰了，就會(huì)破壞整個(gè)系統(tǒng)的性能。最佳的實(shí)踐是擁有兩個(gè)測試系統(tǒng)，一個(gè)用于開發(fā)者的代碼和功能的整合測試， 另一個(gè)要與生產(chǎn)環(huán)境完全一致，從而更容易向生產(chǎn)環(huán)境平滑地過渡。很多開發(fā)者都使用SVN或者類似的方法。如果所有都沒問題，那么它們會(huì)將該版本簽出到生產(chǎn)環(huán)境。遵循這些規(guī)則會(huì)有助于確保系統(tǒng)長久、良好地運(yùn)行。本文試圖從可操作性和可靠性的角度討論最重要的幾點(diǎn)。版本控制應(yīng)該是代碼轉(zhuǎn)移到測試環(huán)境的必經(jīng)之路，而不是簡單地復(fù)制或者使用tar文件，因?yàn)檫@二者都是不可靠的。一個(gè)5~10臺(tái)服務(wù)器的生產(chǎn) 環(huán)境，可以很容易地在辦公室或者IDC中使用一臺(tái)服務(wù)器來復(fù)制，從而用于測試，而這臺(tái)服務(wù)器我們可以用于多個(gè)客戶的項(xiàng)目?！ ?. 構(gòu)建測試和開發(fā)環(huán)境 很多公司只有開發(fā)者的桌面系統(tǒng)和他們的生產(chǎn) 服務(wù)器?！ ?. 使用類似Memcached之類的數(shù)據(jù)庫緩存 即便有了好的數(shù)據(jù)庫設(shè)計(jì)、SQL和讀寫 離，大型的系統(tǒng)仍然需要更快的性能，特別是對(duì)會(huì)話狀態(tài)、好友列表以及BBS文字之類的東西。更一般地，這意味著建立主/從副本系統(tǒng)，其中程序會(huì)對(duì)主庫編寫所有的Update、Insert和Delete變更語句，而所有Select的數(shù)據(jù)都讀取自從數(shù)據(jù)庫（或者多個(gè)從數(shù)據(jù)庫）。 而我們提供給客戶的最佳實(shí)踐文檔足足有10頁那么長。MySQL的Dump是不夠的，因?yàn)樽詈玫膫浞莘椒ㄊ鞘褂肔VM快照和INNODB對(duì)系統(tǒng)進(jìn)行熱備份，從而得到超快的速度和超高的可靠性。我們見到過很多系統(tǒng)每秒會(huì)讀取500,000條數(shù)據(jù)， 這是出現(xiàn)SQL問題的明顯預(yù)兆，但公司往往對(duì)其一無所知直到服務(wù)器開始崩潰。 不幸的是，這些問題一開始并不明顯，直到系統(tǒng)增大、突然開始崩潰的時(shí)候才會(huì)顯現(xiàn)出來
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1