https://blog.csdn.net/u011650048/article/details/51754423

1、圖片壓縮：

靜態(tài)頁面驗(yàn)收時(shí)，檢查每張圖片不能超過200K，每個(gè)頁面不能超過2.5M

CMS后臺(tái)上傳圖片，檢查每張圖片不能超過200K，盡量不要使用原圖，使用壓縮過的圖片

2、圖片合并實(shí)現(xiàn) CSS Sprites

CSS Sprites 是一個(gè)吸引人的技術(shù)，它其實(shí)就是把網(wǎng)頁中一些背景圖片整合到一張圖片文件中，再利用CSS 的“background-image”，“background-repeat”，“background-position”的組合進(jìn)行背景定位，background-position可以用數(shù)字能精確的定位出背景圖片的位置；

利用 CSS Sprites 能很好地減少網(wǎng)頁的HTTP 請(qǐng)求，從而大大的提高了頁面的性能；

能減少圖片的字節(jié)，由于圖像合并后基本信息不用重復(fù)，那么多張圖片合并成 1 張圖片的字節(jié)往往總是小于這些圖片的字節(jié)總和；

更換風(fēng)格方便、維護(hù)方便。

3、預(yù)加載、懶加載

預(yù)加載和懶加載，是一種改善用戶體驗(yàn)的策略，它實(shí)際上并不能提高程序性能，但是卻可以明顯改善用戶體驗(yàn)或減輕服務(wù)器壓力。

預(yù)加載原理是在用戶查看一張圖片時(shí)，就將下一張圖片先下載到本地，而當(dāng)用戶真正訪問下一張圖片時(shí)，由于本地緩存的原因，無需從服務(wù)器端下載，從而達(dá)到提高用戶體驗(yàn)的目的。

懶加載則是在用戶需要的時(shí)候再加載。當(dāng)一個(gè)網(wǎng)頁中可能同時(shí)有上百張圖片，而大部分情況下，用戶只看其中的一部分，如果同時(shí)顯示上百張，則浪費(fèi)了大量帶寬資源，因此可以當(dāng)用戶往下拉動(dòng)滾動(dòng)條時(shí)，才去請(qǐng)求下載被查看的圖像。（JQuery 的懶加載組件）

4、CSS放在頁面的上面，JS放在頁面的下面

瀏覽器會(huì)在下載完全部的css之后才會(huì)對(duì)整個(gè)頁面進(jìn)行渲染，因此最好是將css放在頁面最上面，讓瀏覽器盡快下載css.

JS則相反，瀏覽器在加載js后立即執(zhí)行，有可能會(huì)阻塞整個(gè)頁面，造成頁面顯示緩慢，因此js最好放在頁面最下面。但是也有特殊情況，如果頁面解析時(shí)就需要用到j(luò)s或者有特殊要求必須把js放置在head里面，這時(shí)放在最下面就不合適了

5、盡量減少HTTP請(qǐng)求次數(shù)

剔除重復(fù)腳本：在同一個(gè)頁面中重復(fù)引用JavaScript文件會(huì)影響頁面的性能，重復(fù)腳本會(huì)引起不必要的HTTP請(qǐng)求和無用的JavaScript運(yùn)算，這降低了網(wǎng)站性能

js或css或img文件合并和壓縮，來減少Http請(qǐng)求

ajax異步請(qǐng)求，防止多次請(qǐng)求，程序判斷第一次請(qǐng)求完成后再允許第二次請(qǐng)求

6、不要在HTML中縮放圖片

不要為了在HTML中設(shè)置長(zhǎng)寬而使用比實(shí)際需要大的圖片。

如果你需要：?

那么你的圖片（mycat.jpg）就應(yīng)該是100x100像素而不是把一個(gè)500x500像素的圖片縮小使用。

7、后端高性能開發(fā)

代碼復(fù)雜性,優(yōu)化響應(yīng)速度

代碼越復(fù)雜，性能越不好，越容易出錯(cuò)，我們?cè)诰庉嫶a時(shí)盡量精簡(jiǎn)化、邏輯簡(jiǎn)單化；根據(jù)需求使用最簡(jiǎn)單的方法實(shí)現(xiàn)功能效果；盡量減少對(duì)數(shù)據(jù)庫的操作；減少循環(huán)請(qǐng)求或多次請(qǐng)求的邏輯。

代碼重復(fù)調(diào)用,冗余

css/js/img/php重復(fù)調(diào)用，導(dǎo)致多次請(qǐng)求，影響加載速度和性能

檢查和優(yōu)化代碼，減少重復(fù)調(diào)用請(qǐng)求，從而提高加載速度和優(yōu)化性能

減少代碼冗余

語法嚴(yán)謹(jǐn)、杜絕死循環(huán)邏輯

數(shù)據(jù)緩存（redis/memache）

根據(jù)不同的需求使用不同的緩存技術(shù)（內(nèi)存使用率、數(shù)據(jù)類型、持久性、數(shù)據(jù)安全等條件篩選適合你的緩存技術(shù)）

獲取數(shù)據(jù)庫的數(shù)據(jù)，根據(jù)需求分析是否可以使用緩存，是否要對(duì)數(shù)據(jù)進(jìn)行緩存

mysql優(yōu)化

Explain你的SELECT查詢：使用Explain關(guān)鍵字可以讓你知道MySQL是如何處理你的SQL語句的。這可以幫你分析你的查詢語句或是表結(jié)構(gòu)的性能瓶頸。

當(dāng)只要一行數(shù)據(jù)時(shí)使用LIMIT1：在這種情況下，加上LIMIT1可以增加性能。這樣一樣，MySQL數(shù)據(jù)庫引擎會(huì)在找到一條數(shù)據(jù)后停止搜索，而不是繼續(xù)往后查少下一條符合記錄的數(shù)據(jù)。

為搜索字段建索引：索引并不一定就是給主鍵或是唯一的字段。如果在你的表中，有某個(gè)字段你總要會(huì)經(jīng)常用來做搜索，那么，請(qǐng)為其建立索引

選擇正確的存儲(chǔ)引擎：

?? 1）MyISAM適合于一些需要大量查詢的應(yīng)用，但其對(duì)于有大量寫操作并不是很好。甚至你只是需要update一個(gè)字段，整個(gè)表都會(huì)被鎖起來，而別的進(jìn)程，就算是讀進(jìn)程都無法操作直到讀操作完成。另外，MyISAM對(duì)于SELECT COUNT(*) 這類的計(jì)算是超快無比的。

?? 2）InnoDB的趨勢(shì)會(huì)是一個(gè)非常復(fù)雜的存儲(chǔ)引擎，對(duì)于一些小的應(yīng)用，它會(huì)比MyISAM還慢。他是它支持“行鎖” ，于是在寫操作比較多的時(shí)候，會(huì)更優(yōu)秀。并且，他還支持更多的高級(jí)應(yīng)用，比如：事務(wù)。

垂直分割：“垂直分割”是一種把數(shù)據(jù)庫中的表按列變成幾張表的方法，這樣可以降低表的復(fù)雜度和字段的數(shù)目，從而達(dá)到優(yōu)化的目的。但是你需要注意的是，這些被分出去的字段所形成的表，你不會(huì)經(jīng)常性地去Join他們，不然的話，這樣的性能會(huì)比不分割時(shí)還要差，而且，會(huì)是極數(shù)級(jí)的下降。

把IP地址存成UnsignedInt(無符號(hào)整型)：很多程序員都會(huì)創(chuàng)建一個(gè)VARCHAR(15) 字段來存放字符串形式的IP而不是整型的IP。在PHP中，也有這樣的函數(shù)ip2long()和long2ip()。

讀寫分離、db集群等優(yōu)化

還有其他優(yōu)化可查看該地址：http://blog.csdn.net/waferleo/article/details/7179009

代碼功能監(jiān)控

1）監(jiān)控后臺(tái)設(shè)置監(jiān)控規(guī)則，代碼請(qǐng)求達(dá)到規(guī)則限制時(shí)，發(fā)短信或郵件報(bào)警

2）代碼層面加監(jiān)控代碼，監(jiān)控配置設(shè)置、邏輯在哪一步某一條件時(shí)，需要對(duì)其進(jìn)行提交報(bào)警日志

后端總結(jié)

考慮用戶體驗(yàn)問題，優(yōu)化請(qǐng)求速度、代碼精簡(jiǎn)化、邏輯簡(jiǎn)單化、語法嚴(yán)謹(jǐn)

根據(jù)需求分析是否需要加緩存技術(shù)

功能性活動(dòng)，考慮訪問量問題，代碼邏輯要把高并發(fā)的問題考慮進(jìn)去

mysql的優(yōu)化

功能邏輯如果有必要加一下監(jiān)控代碼

服務(wù)器高性能搭建

網(wǎng)站架構(gòu)規(guī)劃

1)機(jī)房選擇：選擇單線、雙線或多線機(jī)房

2)帶寬大小：根據(jù)網(wǎng)站預(yù)估PV的訪問量來設(shè)置帶寬大小（1G）

3)服務(wù)器劃分：圖片服務(wù)器、頁面服務(wù)器、數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器、日志服務(wù)器等（db讀寫分離、集群）

4)框架選擇：如PHP的YII框架，邏輯分層（MVC）

5)緩存：架構(gòu)層面（apache/varnish）;程序?qū)用?#xff08;redis、memcache）

6)負(fù)載均衡：HTTP協(xié)議、TCP業(yè)務(wù)類型【Nginx輕量級(jí)負(fù)載均衡、高可用；LVS(服務(wù)器集群負(fù)載均衡)+KeepAlived(檢測(cè)服務(wù)器工作是否正常)：實(shí)現(xiàn)負(fù)載均衡和高可用】

http持久鏈接

持久連接（Keep-Alive）也叫做長(zhǎng)連接，它是一種TCP 的連接方式，連接會(huì)被瀏覽器和服務(wù)器所緩存，在下次連接同一服務(wù)器時(shí)，緩存的連接被重新使用。由于HTTP 的無狀態(tài)性，人們也一直很清楚“一次性”的 HTTP通信。持久連接則減少了創(chuàng)建連接的開銷，提高了性能。（在線聊天功能）

GZIP壓縮

為了減少傳輸?shù)臄?shù)據(jù)，壓縮是一個(gè)不錯(cuò)的選擇，而 HTTP協(xié)議支持 GZIP 的壓縮格式，服務(wù)器響應(yīng)的報(bào)頭包含Content-Encoding: gzip，它告訴瀏覽器，這個(gè)響應(yīng)的返回?cái)?shù)據(jù)，已經(jīng)壓縮成GZIP 格式，瀏覽器獲得數(shù)據(jù)后要進(jìn)行解壓縮操作，在一定程度可以減少服務(wù)器傳輸?shù)臄?shù)據(jù)，提高系統(tǒng)性能；

Nginx 的 GZIP配置，Nginx具有更高的性能，利用該配置可以更好的提高性能

CND加速（7天）

CDN即內(nèi)容分發(fā)網(wǎng)絡(luò)。其基本思路是盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?、更穩(wěn)定

通過在網(wǎng)絡(luò)各處放置節(jié)點(diǎn)服務(wù)器所構(gòu)成的在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)之上的一層智能虛擬網(wǎng)絡(luò)，CDN系統(tǒng)能夠?qū)崟r(shí)地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時(shí)間等綜合信息將用戶的請(qǐng)求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。

其目的是使用戶可就近取得所需內(nèi)容，解決 Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。

web集群服務(wù)器配置（一）

機(jī)器數(shù)：6臺(tái)web虛擬機(jī)（跨機(jī)柜高可用），6臺(tái)CMSweb虛擬機(jī)，2臺(tái)cmsdb虛擬機(jī)（從庫只讀，域名訪問高可用），2臺(tái)cmsApi接口redis虛擬機(jī)（VIP高可用）

安裝軟件：varnish、redis、mysql、php

web集群

機(jī)器數(shù)：12、16或20臺(tái)以上web服務(wù)器虛擬機(jī)，以每4臺(tái)為一個(gè)小集群，公司重點(diǎn)游戲大推期訪問量很高的官網(wǎng)，每個(gè)小集群可解析一款高訪問量的官網(wǎng)，其他穩(wěn)定期訪問量不高的官網(wǎng)可以根據(jù)小集群的負(fù)載情況分別解析到負(fù)載不高的小集群中

安裝軟件：varnish、redis、mysql（cms從庫）、php

服務(wù)器監(jiān)控

zabbix:是一個(gè)基于WEB界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級(jí)的開源解決方案。

服務(wù)器端總結(jié)

根據(jù)不同的業(yè)務(wù)，選擇最適合業(yè)務(wù)的方案

架構(gòu)規(guī)范：機(jī)房選擇、寬帶設(shè)置、服務(wù)器劃分、框架選擇、緩存技術(shù)選擇、負(fù)載均衡技術(shù)選擇

長(zhǎng)短鏈接選擇

CDN動(dòng)態(tài)加速或靜態(tài)加速選擇

服務(wù)器配置方案選擇（大集群、小集群）

是否要加監(jiān)控技術(shù)

總結(jié)

以上是生活随笔為你收集整理的高性能网站原则的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。