摘要：業(yè)務(wù)和架構(gòu)不分家，架構(gòu)是建立在對(duì)業(yè)務(wù)的理解之上的。主鍵最好保持順序遞增，隨機(jī)主鍵會(huì)導(dǎo)致聚簇索引樹(shù)頻繁分裂，隨機(jī)增多，數(shù)據(jù)離散，性能下降。沒(méi)有索引的更新，可能會(huì)導(dǎo)致全表數(shù)據(jù)都被鎖住。

本博客并非全部原創(chuàng)，其實(shí)是一個(gè)知識(shí)的歸納和匯總，里面我引用了很多網(wǎng)上、書(shū)上的內(nèi)容。也給出了相關(guān)的鏈接。
本文涉及的知識(shí)點(diǎn)比較多，大家可以根據(jù)關(guān)鍵字去搜索相關(guān)的內(nèi)容和購(gòu)買相應(yīng)的書(shū)籍進(jìn)行系統(tǒng)的學(xué)習(xí)。不對(duì)的地方大家予以批評(píng)指正。
有人給我留言說(shuō)，億級(jí) PV 就別寫(xiě)文章了，隨便用幾個(gè)開(kāi)源軟件就能搞定了，只要不犯什么大錯(cuò)。我不以為然，如果你利用了相同的思想，使用了更高性能的基礎(chǔ)服務(wù)，也許就能支持更多的流量并發(fā)，節(jié)約更多的服務(wù)器，優(yōu)化的思路才是重點(diǎn)。
本內(nèi)容的視頻分享見(jiàn)我的直播

PHP 進(jìn)階之路 - 億級(jí) pv 網(wǎng)站架構(gòu)的技術(shù)細(xì)節(jié)與套路
PHP 進(jìn)階之路 - 億級(jí)pv網(wǎng)站架構(gòu)實(shí)戰(zhàn)之性能壓榨

性能優(yōu)化是建立在對(duì)業(yè)務(wù)的理解之上的

性能優(yōu)化與架構(gòu)、業(yè)務(wù)相輔相成、密不可分的

我們先看一張簡(jiǎn)單的 web 架構(gòu)圖

從上到下從用戶的瀏覽器到最后的數(shù)據(jù)庫(kù)，那么我們說(shuō)先前端的優(yōu)化。

雅虎軍規(guī)：http://www.cnblogs.com/paul-3...

圖片、css、script等等這些都會(huì)增加http請(qǐng)求數(shù)，減少這些元素的數(shù)量就能減少響應(yīng)時(shí)間。

把多個(gè)JS、CSS在可能的情況下寫(xiě)進(jìn)一個(gè)文件，頁(yè)面里直接寫(xiě)入圖片也是不好的做法，應(yīng)該寫(xiě)進(jìn)CSS里，小圖拼合后利用 background 來(lái)定位。

現(xiàn)在很多 icon 都是直接做成字體，矢量高清，也減少網(wǎng)絡(luò)請(qǐng)求數(shù)

現(xiàn)在的前端框架都會(huì)通過(guò)組件的方式開(kāi)發(fā)，最后打包生成一個(gè) js 或者 兩個(gè) js 文件 + 一個(gè) css 或者兩個(gè) css 文件。

expires,cache-control,last-modified,etag
http://blog.csdn.net/eroswang...
防止緩存，比如資源更新了，原來(lái)的做法是?v=xxxx 現(xiàn)在前端的打包工作可以能會(huì)生成 /v1.2.0/xxx.js

接地氣利用 cdn 存儲(chǔ)前端資源

原因一：瀏覽器對(duì)同一域名的并行請(qǐng)求數(shù)有上限，多個(gè)域名則支持更多并行請(qǐng)求

原因二：使用同一域名的時(shí)候無(wú)用的 cookie 簡(jiǎn)直是噩夢(mèng)

開(kāi)啟gzip

前端資源本身的壓縮，js/css 打包編譯（去掉空格，語(yǔ)意簡(jiǎn)化）圖片資源的壓縮等。

資源的按需加載，延時(shí)加載 https://mengkang.net/229.html

圖片的懶加載，淘寶的商品介紹太多圖，用戶點(diǎn)擊進(jìn)來(lái)又有多少人一直往下看圖的呢？

分為下面三個(gè)部分來(lái)

worker_processes auto 設(shè)置多少子進(jìn)程

worker_cpu_affinity 親緣性綁定

worker_rlimit_nofile 65535 worker 進(jìn)程打開(kāi)的文件描述符的最大數(shù)

worker_connections 65535 子進(jìn)程最多處理的連接數(shù)

epoll 多路復(fù)用

sendfile on 是對(duì)文件I/O的系統(tǒng)調(diào)用的一個(gè)優(yōu)化，系統(tǒng)api

如果是反向代理web服務(wù)器，需要配置fastcgi相關(guān)的參數(shù)

數(shù)據(jù)返回開(kāi)啟gzip壓縮

靜態(tài)資源使用 http 緩存協(xié)議

開(kāi)啟長(zhǎng)連接 keepalive_timeout

        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
        fastcgi_buffer_size 64k;
        fastcgi_buffers 4 64k;
        fastcgi_busy_buffers_size 128k;
        fastcgi_temp_file_write_size 256k;

        gzip on;
        gzip_min_length  1k;
        gzip_buffers     4 16k;
        gzip_http_version 1.0;
        gzip_comp_level 2;
        gzip_types       text/plain application/x-javascript text/css application/xml text/javascript application/json;
        gzip_vary on;
        gzip_proxied        expired no-cache no-store private auth;
        gzip_disable        "MSIE [1-6].";

        location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
            {
                expires      30d;
            }    

http://mailman.nginx.org/pipe...

/proc/sys/net/ipv4/tcp_tw_recycle 1 開(kāi)啟TCP連接中TIME-WAIT sockets的快速回收,保證tcp_timestamps = 1

/proc/sys/net/ipv4/tcp_tw_reuse 1 允許將TIME-WAIT sockets重新用于新的TCP連接 https://mengkang.net/564.html

/proc/sys/net/ipv4/tcp_syncookies 0 是否需要關(guān)閉洪水抵御 看自己業(yè)務(wù)，比如秒殺，肯定需要關(guān)閉了

/proc/sys/net/ipv4/tcp_max_tw_buckets 180000 否則經(jīng)常出現(xiàn) time wait bucket table overflow

tcp_nodelay on 小文件快速返回，我之前通過(guò)網(wǎng)絡(luò)掛載磁盤(pán)出現(xiàn)找不到的情況

tcp_nopush on

tcp_tw_recycle 快速回收可能導(dǎo)致丟包的問(wèn)題 https://mengkang.net/1144.html

除了上面的網(wǎng)絡(luò)協(xié)議配置也是在系統(tǒng)基礎(chǔ)之外，為了配合nginx自己里面的設(shè)定需要做如下修改

/proc/sys/net/core/somaxconn 65535

ulimit -a 65535

更多詳細(xì)的優(yōu)化配置說(shuō)明：http://os.51cto.com/art/20140...

注意有很多函數(shù)和擴(kuò)展被廢棄，比如mysql相關(guān)的，有風(fēng)險(xiǎn)，做好測(cè)試再切換。

php 5.5 之后好像就內(nèi)置了吧，需要在php.ini里添加如下配置

opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.max_accelerated_files=1000
opcache.memory_consumption=512
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1

opcache.revalidate_freq

這個(gè)選項(xiàng)用于設(shè)置緩存的過(guò)期時(shí)間（單位是秒），當(dāng)這個(gè)時(shí)間達(dá)到后，opcache會(huì)檢查你的代碼是否改變，如果改變了PHP會(huì)重新編譯它，生成新的opcode，并且更新緩存。

opcache.validate_timestamps

當(dāng)這個(gè)選項(xiàng)被啟用（設(shè)置為1），PHP會(huì)在opcache.revalidate_freq設(shè)置的時(shí)間到達(dá)后檢測(cè)文件的時(shí)間戳（timestamp）。

opcache.max_accelerated_files

這個(gè)選項(xiàng)用于控制內(nèi)存中最多可以緩存多少個(gè)PHP文件。

opcache.memory_consumption

你可以通過(guò)調(diào)用opcachegetstatus()來(lái)獲取opcache使用的內(nèi)存的總量

opcache.interned_strings_buffer

字符串opcache的復(fù)用，單位為MB

opcache.fast_shutdown=1

開(kāi)啟快速停止續(xù)發(fā)事件，依賴于Zend引擎的內(nèi)存管理模塊

Hugepage 的作用：間接提高虛擬地址和內(nèi)存地址轉(zhuǎn)換過(guò)程中查表的TLB緩存命中率

opcache.huge_code_pages=1

鳥(niǎo)哥博客詳細(xì)介紹：http://www.laruence.com/2015/...

以thinkphp為例，它會(huì)把框架基礎(chǔ)組件（必須用到的組件）合并壓縮到一個(gè)文件中，不僅減少了文件目錄查找，文件打開(kāi)的系統(tǒng)調(diào)用。

通過(guò)stracephp-fpm子進(jìn)程，可以清楚系統(tǒng)調(diào)用的過(guò)程，在我上面例子中有打開(kāi)一個(gè)文件有12次系統(tǒng)調(diào)用（只是舉例，我這里相對(duì)路徑設(shè)置的原因?qū)е露嗔藘纱挝募檎遥Ｈ绻?0個(gè)文件，那就是120次，優(yōu)化的效果可能不是那么明顯，但是這是一種思路。
順便說(shuō)下 set_include_path能不用就不要用，上面的demo的截圖里面找不到目錄就是證明。

模板把它們自定義的語(yǔ)法，最后轉(zhuǎn)換成php語(yǔ)法，這樣方便解析。而不是每次都解析一遍。

我的截圖一直上傳不成功，正好社區(qū)有這樣的博客，推薦下 https://segmentfault.com/a/11...

比如原來(lái)有一個(gè)model，叫問(wèn)答，現(xiàn)在需要開(kāi)發(fā)一個(gè)有獎(jiǎng)問(wèn)答，需要支持話題打賞，里面多了很多功能。這個(gè)時(shí)候應(yīng)該利用面向?qū)ο蟮睦^承的特性。而不是做下面的開(kāi)發(fā)

這樣邏輯多了，子類型多了，邏輯判斷就非常重復(fù)，程序運(yùn)行起來(lái)低效可能是一方面，更多的是不可維護(hù)性。
業(yè)務(wù)和架構(gòu)不分家，架構(gòu)是建立在對(duì)業(yè)務(wù)的理解之上的。再放下上次直播的PPT （sf故障無(wú)法傳圖，等會(huì)補(bǔ)吧）
異步思想
舉例：

處理郵件發(fā)送。
gearman 圖片裁剪。
頁(yè)面上 ajax 加載動(dòng)態(tài)數(shù)據(jù)。
圖片的懶加載，雙擊圖片看大圖。
sf 上通過(guò)websocket 通知你有新的消息，但是并沒(méi)有告訴你有什消息，點(diǎn)擊消息圖標(biāo)才會(huì)去異步請(qǐng)求具體的消息。

這些都是異步的思想。能分步走就分步走，能不能請(qǐng)求的就不請(qǐng)求。
靜態(tài)化
專題頁(yè)面，比如秒殺頁(yè)面，為了應(yīng)對(duì)更大的流量、并發(fā)。而且更新起來(lái)也比較方便。
業(yè)務(wù)解耦
比如剛剛上面說(shuō)的專題頁(yè)面，還有必要走整個(gè)框架的一套流程嗎？進(jìn)來(lái)引用一大堆的文件，初始化一大堆的東西？是不是特別低效呢？所以需要業(yè)務(wù)解耦，專題頁(yè)面如果真要框架（可以首次訪問(wèn)之后生成靜態(tài)頁(yè)面）也應(yīng)該是足夠輕量級(jí)的。不能與傳統(tǒng)業(yè)務(wù)混為一談。
分布式以及 soa
說(shuō)業(yè)務(wù)優(yōu)化，真的不得不提架構(gòu)方面的東西，業(yè)務(wù)解耦之后，就有了分布式和soa，因?yàn)檫@在上次分享中已經(jīng)都說(shuō)過(guò)了，就不多說(shuō)了。
只說(shuō)下 soa 自定義 socket 傳輸協(xié)議。

最重要的就是在自定義頭里面強(qiáng)調(diào)body_len，注意設(shè)置為緊湊型，才能保證跨平臺(tái)性 具體說(shuō)明：https://mengkang.net/586.html
Mysql 優(yōu)化
數(shù)據(jù)索引相關(guān)的文章網(wǎng)上很多了，不足的地方大家補(bǔ)充。
表設(shè)計(jì) - 擁抱 innodb
現(xiàn)在大多數(shù)情況都會(huì)使用innodb類型了。具體原因是 mysql 專家給的意見(jiàn)。
我自己對(duì) mysql 的優(yōu)化不了解，每一個(gè)細(xì)分領(lǐng)域都是一片汪洋，每個(gè)人的時(shí)間精力是有限的，所以大家也不用什么都非要深入去研究，往往是一些計(jì)算機(jī)基礎(chǔ)更為重要。
參考這份ppt https://static.mengkang.net/u...
表設(shè)計(jì) - 主鍵索引

innodb 需要一個(gè)主鍵，主鍵不要有業(yè)務(wù)用途，不要修改主鍵。
主鍵最好保持順序遞增，隨機(jī)主鍵會(huì)導(dǎo)致聚簇索引樹(shù)頻繁分裂，隨機(jī)I/O增多，數(shù)據(jù)離散，性能下降。

舉例：
之前項(xiàng)目里有些索引是article_id + tag_id 聯(lián)合做的主鍵，那么這種情況下，就是業(yè)務(wù)了屬性了。主鍵也不是順序遞增，每插入新的數(shù)據(jù)都有可能導(dǎo)致很大的索引變動(dòng)（了解下數(shù)據(jù)庫(kù)b+索引的原理）
表設(shè)計(jì) - 字段選擇

能選短整型，不選長(zhǎng)整型。比如一篇文章的狀態(tài)值，不可能有超過(guò)100種吧，不過(guò)怎么擴(kuò)展，沒(méi)必要用int了。
能選 char 就避免 varchar，比如圖片資源都有一個(gè)hashcode，固定長(zhǎng)度20位，那么就可以選char了。
當(dāng)使用 varchar 的時(shí)候，長(zhǎng)度夠用就行，不要濫用。
大文本多帶帶分離，比如文章的詳情，多帶帶出一張表。其他基本信息放在一張表里，然后關(guān)聯(lián)起來(lái)。
冗余字段的使用，比如文章的詳情字段，增加一個(gè)文章markdown解析之后的字段。

索引優(yōu)化
大多數(shù)情況下，索引掃描要比全表掃描更快，性能更好。但也不是絕對(duì)的，比如需要查找的數(shù)據(jù)占了整個(gè)數(shù)據(jù)表的很大比例，反而使用索引更慢了。

沒(méi)有索引的更新，可能會(huì)導(dǎo)致全表數(shù)據(jù)都被鎖住。所以更新的時(shí)候要根據(jù)索引來(lái)做。
聯(lián)合索引的使用
explain 的使用

聯(lián)合索引“最左前綴”，查詢優(yōu)化器還會(huì)幫你調(diào)整條件表達(dá)式的順序，以匹配組合索引的要求。
CREATE TABLE `test` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `a` int(10) unsigned NOT NULL,
  `b` int(10) unsigned NOT NULL,
  `c` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_abc` (`a`,`b`,`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
能使用到索引
explain select * from test where a=1;
explain select * from test where a=1 and b=2;
explain select * from test where a=1 and b=2 and c=3;
explain select * from test where a=1 and b in (2,3) and c=3;
explain select * from test where a=1 and b=2 order by c desc;
不能使用索引
explain select * from test where a=1 and b in (2,3) order by c desc;
explain select * from test where b=2;
索引更詳細(xì)講解 https://mengkang.net/1302.html

explain 搜到一篇不錯(cuò)的: http://blog.csdn.net/woshiqjs...
很重要的參數(shù)type,key,extra
type 最常見(jiàn)的
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL


值
說(shuō)明



const
通過(guò)索引直接找到一個(gè)匹配行，一般主鍵索引的時(shí)候


ref
沒(méi)有主鍵索引或者唯一索引的條件索引，查詢結(jié)果多行，在聯(lián)合查詢中很常見(jiàn)


index
利用到了索引，有可能有其它排序，where 或者 group by 等


all
全表掃描，沒(méi)有使用到索引



extra
如果有Using filesort或者Using temporary的話,就必須要優(yōu)化了
收集慢查詢
my.ini 配置里增加
long_query_time=2
log-slow-queries=/data/var/mysql_slow.log
使用 nosql
redis 豐富的數(shù)據(jù)類型，非常適合配合mysql 做一些關(guān)系型的查詢。比如一個(gè)非常復(fù)雜的查詢列表可以將其插入zset 做排序列表，然后具體的信息，通過(guò)zset里面的紙去mysql 里面去查詢。
緩存優(yōu)化
多級(jí)緩存
請(qǐng)求內(nèi)緩存
static 變量存儲(chǔ)，比如朋友圈信息流，在一次性獲取20條信息的時(shí)候，有可能，點(diǎn)贊的人里面20條里面有30個(gè)人是重復(fù)的，他們點(diǎn)贊你的a圖片也點(diǎn)贊了你的b圖片，所以這時(shí)，如果能使用static數(shù)組來(lái)存放這些用戶的基本信息就高效了些。
本地緩存
請(qǐng)求結(jié)束了，下拉更新朋友圈，里面又出現(xiàn)了上面的同樣的好友，還得重新請(qǐng)求一次。所以本地常駐內(nèi)存的緩存就更高效了。
分布式緩存
在A服務(wù)器上已經(jīng)查詢過(guò)了，在下拉更新的時(shí)候被分配到B服務(wù)器上了，難道同樣的數(shù)據(jù)再查一次再存到B服務(wù)器的本地緩存里面嗎，弄一個(gè)分布式緩存吧，這樣防止了重復(fù)查詢。但是多了網(wǎng)絡(luò)請(qǐng)求這一步。
很多時(shí)候是三者共存的。
避免緩存的濫用
案例分析


用戶積分更新

比如用戶的基本信息和積分混在一起，當(dāng)用戶登錄的時(shí)候贈(zèng)送積分。則需要更新用戶的積分，這個(gè)時(shí)候更新整個(gè)用戶的基本信息緩存么？
所以這里也可以運(yùn)用下面 hashes 分片的原則去更新


禮物和主題綁定緩存

為了取數(shù)據(jù)方便把多個(gè)數(shù)據(jù)源混合緩存了，這種情況，相比大家可能都見(jiàn)過(guò)，這是災(zāi)難性的設(shè)計(jì)。
{
id:x,
title:x,
gift:{
        id:x,
        name:x,
        img:x,
    }
}
如果需要更新禮物的圖片，那么所有用到過(guò)這個(gè)禮物的話題的緩存都要更新。
redis 使用場(chǎng)景舉例
由于比較基礎(chǔ)基礎(chǔ)好的老司機(jī)就可以忽略了，新人同學(xué)可以看下 https://mengkang.net/356.html
redis 優(yōu)化

多實(shí)例化，更高效地利用服務(wù)器 cpu
內(nèi)存優(yōu)化，官方意見(jiàn) https://redis.io/topics/memor... 有點(diǎn)老
盡可能的使用 hashes ，時(shí)間復(fù)雜度低，查詢效率高。同時(shí)還節(jié)約內(nèi)存。Instagram 最開(kāi)始用string來(lái)存圖片id=>uid的關(guān)系數(shù)據(jù)，用了21g，后來(lái)改為水平分割，圖片id 1000 取模，然后將分片的數(shù)據(jù)存在一個(gè)hashse 里面，這樣最后的內(nèi)容減少了5g，四分之一基本上。

每一段使用一個(gè)Hash結(jié)構(gòu)存儲(chǔ)，由于Hash結(jié)構(gòu)會(huì)在單個(gè)Hash元素在不足一定數(shù)量時(shí)進(jìn)行壓縮存儲(chǔ)，所以可以大量節(jié)約內(nèi)存。這一點(diǎn)在String結(jié)構(gòu)里是不存在的。而這個(gè)一定數(shù)量是由配置文件中的hash-zipmap-max-entries參數(shù)來(lái)控制的。
服務(wù)器認(rèn)知的提升
下面的內(nèi)容，只能是讓大家有一個(gè)大概的認(rèn)識(shí)，了解一個(gè)優(yōu)化的方向，具體的內(nèi)容需要系統(tǒng)學(xué)習(xí)很多很多的知識(shí)。
多進(jìn)程的優(yōu)勢(shì)
多進(jìn)程有利于 CPU 計(jì)算和 I/O 操作的重疊利用。一個(gè)進(jìn)程消耗的絕大部分時(shí)間都是在磁盤(pán)I/O和網(wǎng)絡(luò)I/O中。
如果是單進(jìn)程時(shí)cpu大量的時(shí)間都在等待I/O，所以我們需要使用多進(jìn)程。
減少上下文切換
為了讓所有的進(jìn)程輪流使用系統(tǒng)資源，進(jìn)程調(diào)度器在必要的時(shí)候掛起正在運(yùn)行的進(jìn)程，同時(shí)恢復(fù)以前掛起的某個(gè)進(jìn)程。這個(gè)就是我們常說(shuō)的“上下文切換”。
關(guān)于上下文我之前寫(xiě)一個(gè)簡(jiǎn)單筆記 https://mengkang.net/729.html

無(wú)限制增加進(jìn)程數(shù)，則會(huì)增多 cpu 在各個(gè)進(jìn)程間切換的次數(shù)。
如果我們希望服務(wù)器支持較大的并發(fā)數(shù)，那么久要盡量減少上下文切換的次數(shù)，比如在nginx服務(wù)上nginx的子進(jìn)程數(shù)不要超過(guò)cpu的核數(shù)。
我們可以在壓測(cè)的時(shí)候通過(guò)vmstat,nmon來(lái)監(jiān)控系統(tǒng)上下文切換的次數(shù)。
IOwait 不一定是 I/O 繁忙
# top

top - 09:40:40 up 565 days,  5:47,  2 users,  load average: 0.03, 0.03, 0.00
Tasks: 121 total,   2 running, 119 sleeping,   0 stopped,   0 zombie
Cpu(s):  8.6%us,  0.3%sy,  0.0%ni, 90.7%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
一般情況下IOwait代表I/O操作的時(shí)間占（I/O操作的時(shí)間 + I/O和CPU時(shí)間）的比例。
但是也時(shí)候也不準(zhǔn)，比如nginx來(lái)作為web服務(wù)器，當(dāng)我們開(kāi)啟很多nginx子進(jìn)程，IOwait會(huì)很高，當(dāng)再減少進(jìn)程數(shù)到cpu核數(shù)附近時(shí)，IOwait會(huì)減少，監(jiān)控網(wǎng)絡(luò)流量會(huì)發(fā)現(xiàn)也增加。
多路復(fù)用 I/O 的使用
只要是提供socket服務(wù)，就可以利用多路復(fù)用 I/O 模型。
需要補(bǔ)充的知識(shí) https://mengkang.net/726.html
減少系統(tǒng)調(diào)用
strace 非常方便統(tǒng)計(jì)系統(tǒng)調(diào)用
# strace -c -p 23374
Process 23374 attached - interrupt to quit
^CProcess 23374 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 30.68    0.000166           0       648           poll
 12.01    0.000065           0       228           munmap
 11.65    0.000063           0       228           mmap
 10.54    0.000057           0       660           recvfrom
 10.35    0.000056           0       708           fstat
  7.76    0.000042           0       252           open
  6.10    0.000033           1        36           write
  5.73    0.000031           0        72        24 access
  5.18    0.000028           0        72           read
  0.00    0.000000           0       276           close
  0.00    0.000000           0        13        13 stat
  0.00    0.000000           0       269       240 lstat
  0.00    0.000000           0        12           rt_sigaction
  0.00    0.000000           0        12           rt_sigprocmask
  0.00    0.000000           0        12           pwrite
  0.00    0.000000           0        48           setitimer
  0.00    0.000000           0        12           socket
  0.00    0.000000           0        12           connect
  0.00    0.000000           0        12           accept
  0.00    0.000000           0       168           sendto
  0.00    0.000000           0        12           shutdown
  0.00    0.000000           0        48           fcntl
  0.00    0.000000           0        12           flock
  0.00    0.000000           0       156           getcwd
  0.00    0.000000           0        24           chdir
  0.00    0.000000           0        24           times
  0.00    0.000000           0        12           getuid
------ ----------- ----------- --------- --------- ----------------
100.00    0.000541                  4038       277 total
通過(guò)strace查看“系統(tǒng)調(diào)用時(shí)間”和“調(diào)用次數(shù)”來(lái)定位問(wèn)題 https://huoding.com/2013/10/0...
自己構(gòu)建web服務(wù)器
要想理解web服務(wù)器優(yōu)化的原理，最好的辦法是了解它的來(lái)龍去脈，實(shí)踐就是最好的方式，我分為以下幾個(gè)步驟：

用 PHP 來(lái)實(shí)現(xiàn)一個(gè)動(dòng)態(tài) Web 服務(wù)器 https://mengkang.net/491.html

簡(jiǎn)單靜態(tài) web 服務(wù)器（循環(huán)服務(wù)器）的實(shí)現(xiàn) https://mengkang.net/563.html

多進(jìn)程并發(fā)的面向連接 Web 服務(wù)器的實(shí)踐 https://mengkang.net/571.html

簡(jiǎn)單靜態(tài) Select Web 服務(wù)器的實(shí)現(xiàn) https://mengkang.net/568.html

I/O 多路復(fù)用 https://mengkang.net/726.html


上面是我的學(xué)習(xí)筆記，圖片資源丟失了，大家可以根據(jù)相關(guān)關(guān)鍵詞去搜搜相關(guān)的文章和書(shū)籍，更推薦大家去看書(shū)。