張文豪 陳平華

(廣東工業(yè)大學計算機學院 廣東 廣州 510006)

0 引 言

PHP路由就是網(wǎng)頁請求地址與PHP應用系統(tǒng)中的處理程序的映射關系，其最大的作用就是將一個網(wǎng)頁請求地址解析為調(diào)用的程序地址。正則表達式一般可應用于字符串的檢索功能，市場主流的PHP路由就是利用正則表達式檢索網(wǎng)頁請求地址從而確定調(diào)用的程序地址。正則表達式路由分為獨立的正則表達式和組合的正則表達式。獨立的正則表達式路由由于正則表達式數(shù)量與路由數(shù)量相同，路由檢索時，正則匹配次數(shù)較多，性能低下。Nikita[1]提出了組合的正則表達式路由，減少了正則表達式的數(shù)量和匹配次數(shù)從而提升了正則表達式路由的性能。但是隨著路由數(shù)量的增加，組合的正則表達式的數(shù)量也隨著增加，路由匹配性能下降太快，并且對于組合的正則表達路由的分塊大小只給出簡單的判斷，沒有進行詳細的測試分析。

正則表達式編譯后得到的字符串是有長度限制的[2]，超過最大的長度時，正則表達式就無法進行匹配，必須對組合的正則表達式進行分塊，確保不會超過正則表達式的長度限制。正則表達式的字符串越長編譯后得到的字符串也越長，進行匹配時性能也會相應下降，合理的分塊大小才能使性能達到最佳。組合的正則表達式為了能夠準確找到命中的路由，不同的組合方式有不同的解決方案，但都需要增加輔助字符串，會減少可以進行組合的路由數(shù)量，因此采用不同的組合方式也會直接影響到路由的性能。

為了解決路由數(shù)量較多時，路由匹配給系統(tǒng)帶來的性能壓力，本文對組合的正則表達式路由的組合方式和分塊大小進行測試對比，找出最優(yōu)的組合方式和分塊大小的規(guī)律，并對PHP內(nèi)核進行深入研究，從PHP底層的機制對PHP路由的實現(xiàn)進行深入的優(yōu)化。通過對組合的正則表達式路由的深入優(yōu)化，讓PHP路由的性能在極端情況下，也能保持性能的穩(wěn)定。

1 相關工作

隨著Ruby On Rails的火爆，PHP也隨著它的盛行進入了框架開發(fā)的時代。為了解決使用開發(fā)框架后造成URL訪問地址冗長的問題，開發(fā)框架都提供了路由的功能來實現(xiàn)URL訪問地址的優(yōu)化，并且有利于搜索引擎的收錄，路由也成為開發(fā)框架的核心功能[3]。在開發(fā)框架強制開啟路由后，每個請求地址都要經(jīng)過路由匹配后才能確定要調(diào)用的程序文件，路由匹配是每個請求的必經(jīng)環(huán)節(jié)，成為影響系統(tǒng)性能的關鍵因素。

正則表達式從一開始就被應用到開發(fā)框架的路由組件中，通常使用的是獨立的正則表達式方案，就是一條正則表達式表示一條路由信息，路由匹配時需要逐一匹配直到找到相應的路由。由于獨立的正則表達式方案具有簡單、靈活的特點，在各種程序語言的開發(fā)框架上得到廣泛應用。但獨立的正則表達式方案在路由信息較多時，性能損耗比較嚴重，路由的性能直接影響到開發(fā)框架的性能，因此提升路由的性能就可以提升開發(fā)框架的性能。

2014年1月我國臺灣省的林佑安發(fā)布了Pux 1.0，當時的測試數(shù)據(jù)，路由的性能比Symfony2的路由快了4倍，拉開了提升PHP開發(fā)框架路由性能的序幕。Pux取得的性能的提升引起了很多PHP開發(fā)人員的注意，其中也包括PHP核心組開發(fā)成員：Nikita Popov。Nikita Popov在研究了Pux的實現(xiàn)后，發(fā)現(xiàn)Pux只是簡單地把PHP路由使用C語言編寫為PHP擴展，還是采用了獨立的正則表達式的方案，也就是性能的提升主要來自PHP擴展是靜態(tài)的，減少了PHP程序需要一邊解釋一邊執(zhí)行的時間。2014年2月Nikita Popov提出了基于組合的正則表達式的路由方案，詳細描述了兩種組合的方式：GCB和GPB，并通過綜合的測試，證明即使使用PHP程序進行實現(xiàn)，其綜合性能還是明顯優(yōu)于Pux，并在2014年4月發(fā)布了基于組合的正則表達式的PHP路由庫：FastRoute。在FastRoute發(fā)布后，全球最流行的PHP開發(fā)框架laravel的精簡版本Lumen的路由就采用了FastRoute的實現(xiàn)。2018年2月Symfony發(fā)布4.1版本時，路由組件增加了組合的正則表達式的實現(xiàn)方案，并且組合的正則表達式方案使用方法和獨立的正則表達式方案保持一致，同時在400條靜態(tài)路由和400條動態(tài)路由的狀態(tài)下，測試發(fā)現(xiàn)組合的正則表達式路由方案的性能比獨立的正則表達式路由方案提升了5倍[4]。Symfony路由組件證明了組合的正則表達式路由方案可以在保持簡單、靈活的基礎上，有效地提升路由的綜合性能。從此，組合的正則表達式在PHP開發(fā)框架的路由組件中得到了廣泛的應用，目前也是被廣泛認可的提升路由性能的有效方案。

2 定 義

定義1路由是一個網(wǎng)絡工程的術語，是指分組從源到目的地時，決定端到端路徑的網(wǎng)絡范圍的進程。Web開發(fā)中的路由是指如何定義應用的端點(URIs)以及如何響應客戶端的請求，是由一個URI、HTTP請求和調(diào)用程序組成[5]。

定義2正則表達式，又稱規(guī)則表達式(Regular Expression，在代碼中常簡寫為regex、regexp)，計算機科學的一個概念。正則表達式是對字符串進行描述和通配操作的一種邏輯公式，通常被用來檢索、替換那些符合某個模式(規(guī)則)的文本[6]。

正則表達式是對字符串(包括普通字符(例如，a到z之間的字母)和特殊字符(稱為“元字符”))操作的一種邏輯公式，就是用事先定義好的一些特定字符及這些特定字符的組合，組成一個“規(guī)則字符串”，這個“規(guī)則字符串”用來表達對字符串的一種過濾邏輯。正則表達式是一種文本模式，該模式描述在搜索文本時要匹配的一個或多個字符串。

正則表達式使用小括號(……)構建分組，可以將多個正則表達式通過分組的語法組合為一個大的正則表達式。正則表達式分組分為捕獲組和非捕獲組，捕獲組匹配時會從左到右自動生成組號，支持反向的引用，非捕獲組沒有生成組號，不支持反向引用[7-8]。

定義3正則表達式路由就是使用正則表達式來表示路由規(guī)則，包括路由定義和路由匹配兩部分。路由定義就是使用正則表達式完成路由規(guī)則的定義。路由匹配即路由命中，就是根據(jù)路由定義時用的正則表達式與請求地址進行正則匹配，正則表達式匹配就表示該路由命中，同時根據(jù)正則匹配的結果和路由定義的規(guī)則進行處理，得到一個程序調(diào)用的目標地址。

根據(jù)正則表達式與路由的對應關系，又分為獨立的正則表達式路由和組合的正則表達式路由。

獨立的正則表達式路由就是一條正則表達對應一條路由，路由搜索時，通過列表循環(huán)方式，依次檢測每條路由的正則表達式是否與請求地址正則匹配，如果匹配就代表該路由命中，終止循環(huán)；循環(huán)結束還是沒有正則表達式匹配就代表沒有路由命中。

組合的正則表達式路由就是一條正則表達式對應多條路由，通常還得使用分塊限制正則表達式的長度，路由搜索時也是通過列表循環(huán)方式，依次檢測每條組合后的正則表達式是否匹配，如果組合后的正則表達式與請求地址匹配，還需要根據(jù)組合的方式計算出命中的路由；如果循環(huán)結束還是沒有正則表達式能匹配請求地址就代表沒有路由命中。正則表達式的組合有兩種格式，分別為(?:)和(?|)[7-8]。兩種組合的格式都可以使用“|”構造多個分支。每個分組分支可以包含多個子組，代表一條路由信息。

3 相關數(shù)據(jù)

假設有一個資訊類網(wǎng)站，每個子站有5條路由信息，分別為主頁、欄目頁、列表頁、詳細頁、搜索頁，并且每個子站都指定了子域名(t1到tN)，如表1所示。本文通過增加和減少子站數(shù)量來控制測試的路由數(shù)量。

表1 子站t1的路由信息示例(域名為：t1.xqkeji.com)

舉例說明：

(1) 訪問http[s]://t1.xqkeji.com/后，主頁面的路由被選中，得到調(diào)用程序的地址為：info模塊里的default類的index方法，方法的參數(shù)為100。

(2) 訪問http[s]://t1.xqkeji.com/category/1000后，欄目頁的路由被選中，得到調(diào)用程序的地址為：info模塊里的default類的category方法，方法的參數(shù)為路由正則匹配結果的第一個參數(shù)值(1 000)。

(3) 訪問http[s]://t1.xqkeji.com/list/1001后，列表頁的路由被選中，得到調(diào)用程序的地址為：info模塊里的default類的list方法，方法的參數(shù)為路由正則匹配結果的第一個參數(shù)值(1 001)。

(4) 訪問http[s]://t1.xqkeji.com/show/100001后，詳細頁的路由被選中，得到調(diào)用程序的地址為：info模塊里的default類的show方法，方法的參數(shù)為路由正則匹配結果的第一個參數(shù)值(100 001)。

(5) 訪問http[s]://t1.xqkeji.com/search/后，搜索頁的路由被選中，得到調(diào)用程序的地址為：info模塊里的default類的search方法。

4 算 法

基于正則表達式的路由算法有兩種形式：獨立的正則表達式路由和組合的正則表達式路由。

本文的路由的基本格式：([域名1|域名2|.*?])_([請求方法1|請求方法2|.*?])_路由規(guī)則。

4.1 獨立的正則表達式路由

獨立的正則表達式路由就是一條正則表達式表示一條路由信息，通常將所有的正則表達式路由信息存放到一個數(shù)組中，通過數(shù)組遍歷逐條進行正則匹配，只要有一條正則表達式匹配成功，就退出數(shù)組遍歷，該匹配成功的路由信息為需要調(diào)用的程序地址，如果直到數(shù)組遍歷結束還沒有一條正則表達式匹配成功，就表示找不到路由，返回404錯誤。

根據(jù)子站點t1的路由信息，給出相應的獨立的正則表達式的路由信息。

＄regexes=[

//主頁路由正則表達式

′#^(t1.xqkeji.com)_(get|post)_/＄#′,

//欄目頁路由正則表達式

′#^(t1.xqkeji.com)_(get|post)_/c ategory(/.*)*＄#′,

//列表頁路由正則表達式

′#^(t1.xqkeji.com)_(get|post)_/list(/.*)*＄#′,

//詳細頁路由正則表達式

′#^(t1.xqkeji.com)_(get|post)_/show(/.*)*＄#′,

//搜索頁路由正則表達式

′#^(t1.xqkeji.com)_(get|post)_/search/＄#′,

];

算法描述：

//系統(tǒng)所有路由的正則表達式的數(shù)組

regexes ← 路由正則數(shù)組

//格式為：請求域名_請求方法_請求地址

//例如：t1.xqkeji.com_get_/表示主頁的請求地址

url ← 特定格式的URL信息字符串

//是否路由匹配，初始0表示沒有路由匹配

matched ← 0

//路由數(shù)組的索引下標，確定匹配的路由

route_index ← 0

For regex From regexes

//正則匹配就是測試url地址字符串是否符合正則表達式

//regex的規(guī)則，返回true或false，同時將正則搜索的結果存儲

//到matches數(shù)組中

If 正則匹配(regex,url,matches) Then

//已經(jīng)找到路由

matched ← 1

BREAK

End If

route_index ← route_index+1

End For

If matched Then

//route_index為選中的路由

Else

//沒有找到路由，404錯誤

End If

4.2 組合的正則表達式路由

組合的正則表達式路由就是將多條正則表達式路由信息通過正則表達式的分組語法規(guī)則組合成為一條大的正則表達式，也就是用一條大的正則表達式表示多條路由信息。PHP路由的組合方式主要有三種：基于分組位置(GPB)、基本分組計數(shù)(GCB)和基本分組標記(GMB)。

1) 基于分組位置(GPB)就是根據(jù)正則表達式的匹配結果的分組位置計算出正則表達式命中的分支，也就是命中的路由。GPB組合的特點：以“(?:”開頭；每個分支的分組數(shù)量一致；所有分組位置從左到右遞增；分支匹配后，前面沒有匹配的分支的分組位置都會填充空白符，如圖1所示。

圖1 GPB組合示例圖

假設分支3的正則規(guī)則匹配，那么分支1和分支2的分組都會被填充空白符。正則匹配結果為：

[

0=>全匹配的結果，

1=>”,//分支1的分組1填充空白符

2=>”,//分支1的分組2填充空白符

……

7=>分支3分組7的匹配結果數(shù)據(jù)，

8=>分支3分組8的匹配結果數(shù)據(jù)，

9=>分支3分組9的匹配結果數(shù)據(jù)

]

根據(jù)匹配結果里有9個分組和每個分支有3個分組可以計算出“分支3”命中。

GPB的組合的路由的正則表達式的格式：′#^(?:主頁路由正則表達式()()()()|欄目頁路由正則表達式()()()|列表頁路由正則表達式()()()|詳細頁路由正則表達式()()()|搜索頁正則表達式()()()())＄#’，GPB必須保證所有正則分支的子組數(shù)都相同，也就是取所有分支中的最大分組數(shù)，其他分支添加多余的空分組來確保所有分支的分組數(shù)相同，本例的最大分組數(shù)和相同的分組數(shù)為6。

算法描述：

regex ← 所有路由組合成的GPB正則表達式

//格式為：請求域名_請求方法_請求地址

//例如：t1.xqkeji.com_get_/表示主頁的請求地址

url ← 特定格式的URL信息字符串

//路由數(shù)組的索引下標，確定匹配的路由

route_index ← 0

//正則匹配就是測試url地址字符串是否符合正則表達式

//regex的規(guī)則，返回true或false，同時將正則搜索的結果存儲

//到matches數(shù)組中

If 正則匹配(regex,url,matches) Then

//正則表達式有匹配，說明已經(jīng)找到路由

//6為所有分支最大和相同的分組數(shù)

//計算出命中路由的索引

route_index ← (統(tǒng)計數(shù)組元素數(shù)量(matches)-1)/6-1

Else

//沒有找到路由，404錯誤

End If

2) 基于分組計數(shù)(GCB)就是根據(jù)正則表達式的匹配結果中每個分支的分組數(shù)量是遞增計數(shù)的特點來計算出正則表達式命中的分支，也就是命中的路由。GCB組合的特點：以“(?|”開頭；每個分支的分組數(shù)量不一樣并且是遞增的；所有分支的分組位置是獨立的；分支匹配后，前面沒有匹配的分支的分組位置不會填充空白符，如圖2所示。

圖2 GCB組合示例圖

假設分支3的正則規(guī)則匹配，那么正則匹配結果為：

[

0=>全匹配的結果，

1=>分支3分組1的匹配結果數(shù)據(jù)，

2=>分支3分組2的匹配結果數(shù)據(jù)，

3=>分支3分組3的匹配結果數(shù)據(jù)，

4=>分支3分組4的匹配結果數(shù)據(jù)，

5=>分支3分組5的匹配結果數(shù)據(jù)

]

根據(jù)匹配結果里有5個分組數(shù)和分支3的分組數(shù)一致可以計算出“分支3”命中。

GCB的組合格式：′#^(?|主頁路由正則表達式()()()()|欄目頁路由正則表達式()()()()|列表頁路由正則表達式()()()()()|詳細頁路由正則表達式()()()()()()|搜索頁正則表達式()()()()()()()())＄#’，GCB必須保證所有正則分支的分組數(shù)是遞增的并且有確定的最小分組數(shù)，在這里最小的分組數(shù)是6，主頁的分組數(shù)為6、欄目頁的分組數(shù)為7、列表頁的分組數(shù)為8、詳細頁的分組數(shù)為9、搜索頁的分組數(shù)為10。

算法描述：

regex ← 所有路由組合成的GCB正則表達式

//格式為：請求域名_請求方法_請求地址

//例如：t1.xqkeji.com_get_/表示主頁的請求地址

url ← 特定格式的URL信息字符串

//路由數(shù)組的索引下標，確定匹配的路由

route_index ← 0

//正則匹配就是測試url地址字符串是否符合正則表達式

//regex的規(guī)則，返回true或false，同時將正則搜索的結果存儲

//到matches數(shù)組中

If 正則匹配(regex,url,matches) Then

//正則表達式有匹配，說明已經(jīng)找到路由

//6為所有分支最大和相同的分組數(shù)

//計算出命中路由的索引

route_index ← 統(tǒng)計數(shù)組元素數(shù)量(matches)-7

Else

//沒有找到路由，404錯誤

End If

3) 基于分組標記(GMB)就是根據(jù)正則表達式的匹配結果的分支標記數(shù)據(jù)來確定命中的分支，也就是命中的路由。GMB組合的特點：以“(?|”開頭；每個分支的分組數(shù)量沒有限制；每個分支需要設置唯一的標記；分支匹配后，該分支的標記會填充到匹配的結果中，通過分支標記的數(shù)據(jù)能很容易確定命中的路由，如圖3所示。

圖3 GMB組合示例圖

假設分支3的正則規(guī)則匹配，那么正則匹配結果為：

[

0=>全匹配的結果，

1=>分支3分組1的匹配結果數(shù)據(jù)，

MARK=>分支標記3的數(shù)據(jù)，

]

根據(jù)匹配結果的MARK數(shù)據(jù)就能確定“分支3”命中。

GMB的組合格式：′#^(?|主頁路由正則表達式(*MARK:0)|欄目頁路由正則表達式(*MARK:1)|列表頁路由正則表達式(*MARK:2)|詳細頁路由正則表達式(*MARK:3)|搜索頁正則表達式(*MARK:4))＄#’，GMB通過為每一個組合的分支添加一個唯一的標記，不需要添加多余的正則表達式的空分組()。

算法描述：

regex ← 所有路由的GMB正則表達式

//格式為：請求域名_請求方法_請求地址

//例如：t1.xqkeji.com_get_/表示主頁的請求地址

url ← 特定格式的URL信息字符串

//路由數(shù)組的索引下標，確定匹配的路由

route_index ← 0

//正則匹配就是測試url地址字符串是否符合正則表達式

//regex的規(guī)則，返回true或false，同時將正則搜索的結果存儲

//到matches數(shù)組中

If 正則匹配(regex,url,matches) Then

//正則表達式有匹配，說明已經(jīng)找到路由

//計算出命中路由的索引

route_index ← matches[‘MARK’]

Else

//沒有找到路由，404錯誤

End If

5 實現(xiàn)方案

本文綜合了Pux、FastRoute、Symfony Routing各自的優(yōu)點，采用C語言實現(xiàn)PHP擴展的方式，提升程序性能，并且結合PHP內(nèi)核的機制進行路由性能的優(yōu)化；對組合方式和分塊大小進行深入研究，經(jīng)測試和分析表明GMB是最優(yōu)的組合方式，同時發(fā)現(xiàn)了最優(yōu)的分塊大小是動態(tài)的，是隨著路由信息總數(shù)量的變化而變化的，并提出一個最優(yōu)分塊大小的范圍。

5.1 分塊大小

正則表達式是有長度的限制的，PHP默認使用的是16-bit PCRE2 library，支持的正則表達式編譯后的結果的最大長度為65 536，這就造成了進行組合的正則表達式路由必須進行分塊，將一條大的正則表達式分成多個小塊，才能確保不會超出正則表達式長度的限制。由于限制的長度是正則表達式編譯后的長度，我們很難計算出GPB和GCB組合支持最大的路由數(shù)。經(jīng)過簡單的測試，以每個分支最多6個分組為例，GPB組合一條正則表達式大概支持400條路由，GCB組合一條正則表達式大概支持100條路由，GMB組合一條正則表達式大概支持600條路由，如表2和表3所示。

表2 GPB組合產(chǎn)生的空分組數(shù)

表3 GCB組合產(chǎn)生的空分組數(shù)

例如使用t1-t20構建100條路由，GPB組合產(chǎn)生17×20=340個空分組，GCP組合產(chǎn)生17×20+((20×5-1)(20×5-1+1))/2=340+4 950，GMB組合只加了一個唯一的標記沒有空分組。每一個空分組()由兩個字符組合，GPB的空分組會產(chǎn)生680個字符，GCB的空分組會產(chǎn)生10 580個字符。這是造成GCB一條正則表達式大概最多只支持100條路由、GPB可以達到400條路由、GMB可以達到600條路由的原因。

采用分塊后，GPB、GCB、GMB三種組合都不是每條正則表達式包含最多的路由數(shù)時達到性能最佳。由于正則的匹配性能是不穩(wěn)定的，經(jīng)過簡單測試，三種組合的最佳分塊大小大概等于：

最大數(shù)(最小數(shù)(路由總數(shù)量×G,GMax),GMin)

其中：G在0.3～0.7之間，一般取0.5；Gmin在GPB和GCB中一般取10，在GMB中一般取30；GMax在GPB中一般取300，在GCB中一般取70，在GMB中一般取550。

5.2 采用的組合方式

根據(jù)5.1節(jié)的描述，無論是GPB還是GCB，都需要額外添加空分組()，才能正確計算出匹配的路由，并且隨著分支數(shù)的增加，空分組的數(shù)量就會越多。

同時構建t1-t20個子站點，總共100條路由信息，分別使用GPB、GCB和GMB，匹配t1、t10、t20站點的第一條路由和最后一條路由，測試驗證三種組合方式的性能，結果如圖4所示。

圖4 三種組合方式性能測試

根據(jù)測試的結果，在t1、t10、t20中，采用GMB組合的路由性能比GCB和GPB都有明顯的優(yōu)勢。同時從測試的結果看，在路由數(shù)量較少時，GCB和GMB的性能接近；隨著路由數(shù)量的增加，GCB組合添加的輔助字符越多，與GMB組合的性能差距就越大。

GMB組合的優(yōu)勢在于添加的輔助字符是最少的，同時限制也是最少的，并沒有最小分組數(shù)和相同分組數(shù)的限制，這就決定了GMB對比其他組合方式有明顯的優(yōu)勢。

5.3 其 他

1) 路由格式。([域名1|域名2|.*?])_([請求方法1|請求方法2|.*?])_路由規(guī)則(*MARK:分支唯一標記)

該格式簡單并且支持多域名和多個請求方法，容易編譯成一條大的正則表達式。

2) 路由分類。根據(jù)路由信息的特點，將路由分為靜態(tài)路由和動態(tài)路由。路由進行分類后，靜態(tài)路由不需要進行正則匹配，直接根據(jù)請求的URL地址與目標程序的對應關系，可以采用哈希表進行路由匹配，從而減少了正則表達式的數(shù)量。例如t1站點的主頁和搜索頁，對應的規(guī)則分別為’/’和’/search’，直接與請求的URL地址對應，無須使用正則匹配，就能確定調(diào)用的目標程序地址。

3) 自定義正則匹配函數(shù)。使用preg_match進行路由匹配返回的結果中，我們只需要得到模塊名稱、控制器名稱、動作名稱和參數(shù)四個數(shù)據(jù)，其他數(shù)據(jù)只是為了輔助驗證，不需要通過PHP再返回。通過自定義preg_match函數(shù)，改為調(diào)用PCRE進行正則匹配后，直接返回正則分支的MARK唯一標記，不匹配時返回false，方便直接得到選中的路由索引，并將匹配的結果修改為只返回4個我們需要的數(shù)據(jù)，可以減少PHP將PCRE的匹配結果轉化為PHP數(shù)據(jù)時3次插入數(shù)據(jù)。

4) 使用持久數(shù)組存儲路由信息。PHP每次請求結束都會進行垃圾回收，所有非持久的資源都會被銷毀[9-10]。在沒有將路由信息存儲在持久數(shù)組中時，每一次請求都要加載路由信息。路由信息數(shù)量較多時，加載路由信息就會變成系統(tǒng)的瓶頸。將路由信息存儲在持久數(shù)組中，每一個進程只需加載一次，第二次請求無須加載路由信息，可以有效解決加載大量路由信息對性能造成的影響。

5) 使用LRU緩存路由命中結果。每個請求地址對應的路由信息是固定的，它們之間是一一對應的關系，可以使用緩存來表示它們之間對應的關系，從而減少正則匹配的次數(shù)，提升路由的性能。但是一個普通的網(wǎng)站日點擊率也會超過10萬次，因此緩存必須要有淘汰的策略，不然緩存的信息量太大，會耗盡系統(tǒng)資源，反而會成為負擔。

LRU是Least Recently Used的縮寫，即最近最少使用，是一種常用的頁面置換算法，選擇最近最久未使用的頁面予以淘汰[11]。結合PHP內(nèi)核提供的HashTable和雙向鏈表數(shù)據(jù)結構，實現(xiàn)了一個路由命中結果的LRU緩存，如圖5所示。

圖5 使用緩存的路由匹配流程

啟用LRU緩存后，使用Web請求的url地址作為HashTable的Key,然后LRU節(jié)點存儲路由匹配返回的結果。路由匹配前，檢查該Web請求的url地址是否存在緩存，存在時直接返回緩存中存儲的路由匹配結果，不存在時進行路由匹配并將路由匹配結果寫入緩存最后返回路由匹配結果。

6 實驗與結果

6.1 實驗環(huán)境

1) 軟件環(huán)境。操作系統(tǒng)：Windows 10。軟件環(huán)境：Docker19.03.5、PHP7.4.1。PHP基準測試庫：nice/bench 1.0。

2) 硬件環(huán)境。處理器：Intel(R) Core(TM) i5- 3230M。內(nèi)存：8.00 GB(1 600 MHz)。硬盤：系統(tǒng)盤(固態(tài)硬盤Lenovo SSD SL700 128 GB)，數(shù)據(jù)盤(機械硬盤WDC WD5000LPVT- 08G33T1)。

6.2 產(chǎn)品對比

FastRoute是第一個實現(xiàn)組合的正則表達式路由方案的PHP開源項目，同時被應用于Lumen框架中。它那提出的組合的正則表達式路由的實現(xiàn)方案被大量的項目借鑒，使得正則表達式路由的匹配性能有了數(shù)量級的提升。

Routing(Compiled)是PHP著名的開發(fā)框架Symfony的路由組件中的一種路由匹配方式，是在Symfony 4.1版本后借鑒了FastRoute的組合的正則表達式路由的實現(xiàn)方案，實現(xiàn)了將Routing的路由信息編譯為組合的正則表達式路由的實現(xiàn)方案,對比獨立的正則表達式路由有5倍性能的提升。

XqRoute是采用本文制定的實現(xiàn)方案，實現(xiàn)的高性能的PHP路由庫。

XqRoute(LRU)是在XqRoute下開啟了LRU緩存，開啟LRU緩存后可以讓路由的匹配不受路由信息數(shù)量的影響，保持穩(wěn)定的路由性能。

6.3 構建實驗數(shù)據(jù)

通過構建t1-t20、t1-t100、t1-t200等，生成100條、500條、1 000條路由信息。

6.4 測試對比

1) 100條路由。連續(xù)運行10 000次，對比t1、t10、t20站點5條路由都匹配一次和一次沒有路由匹配的情況，如圖6所示。

圖6 100條路由(t1-t20)的路由匹配性能對比

2) 500條路由。連續(xù)運行10 000次，對比t1、t50、t100站點5條路由都匹配一次和一次沒有路由匹配的情況，如圖7所示。

圖7 500條路由(t1-t100)的路由匹配性能對比

3) 1 000條路由。連續(xù)運行10 000次，對比t1、t100、t200站點5條路由都匹配一次和一次沒有路由匹配的情況，如圖8所示。

圖8 1 000條路由(t1-t200)的路由匹配性能對比

6.5 測試結論

根據(jù)測試的路由信息，只有60%的路由是動態(tài)路由，也就是100條路由時，只有60條動態(tài)路由。FastRoute在動態(tài)路由信息較少時，性能表現(xiàn)比較好，但隨著動態(tài)路由信息的增加，性能下降較快。XqRoute即使沒有開啟LRU緩存，綜合性能也是最好的，隨著動態(tài)路由信息的增加，性能只是緩慢下降，動態(tài)路由信息越多，性能優(yōu)勢越明顯。XqRoute啟用LRU緩存后，可以使得路由匹配的性能基本與動態(tài)路由信息的數(shù)量無關。

7 結 語

本文深入研究了組合的正則表達式路由的組合方式和分塊大小，并制定了一個可行的高性能的PHP路由實現(xiàn)方案，實現(xiàn)了一個不受動態(tài)路由信息數(shù)量影響的高性能的PHP路由庫。接下來將在此基礎上，繼續(xù)研究和實現(xiàn)開發(fā)框架的其他核心組件，最終實現(xiàn)一個通用的高性能的高效率的PHP開發(fā)框架。