您好,登錄后才能下訂單哦!
這篇文章主要介紹composer autoload自動加載性能優化的示例,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
composer 提供的 autoload 機制使得我們組織代碼和引入新類庫非常方便,但是也使項目的性能下降了不少 。
composer autoload 慢的主要原因在于來自對 PSR-0 和 PSR-4 的支持,加載器得到一個類名時需要到文件系統里查找對應的類文件位置,這導致了很大的性能損耗,當然這在我們開發時還是有用的,這樣我們添加的新的類文件就能即時生效。 但是在生產模式下,我們想要最快的找到這些類文件,并加載他們。
因此 composer 提供了幾種優化策略,下面說明下這些優化策略。
第一層級(Level-1)優化: 生成 classmap
如何運行:
執行命令 composer dump-autoload -o
(-o 等同于 --optimize)
原理:
這個命令的本質是將 PSR-4/PSR-0 的規則轉化為了 classmap 的規則, 因為 classmap 中包含了所有類名與類文件路徑的對應關系,所以加載器不再需要到文件系統中查找文件了。可以從 classmap 中直接找到類文件的路徑。
注意事項
建議開啟 opcache , 這樣會極大的加速類的加載。
php5.5 以后的版本中默認自帶了 opcache 。
這個命令并沒有考慮到當在 classmap 中找不到目標類時的情況,當加載器找不到目標類時,仍舊會根據PSR-4/PSR-0 的規則去文件系統中查找
第二層級(Level-2/A)優化:權威的(Authoritative)classmap
執行命令:
執行命令 composer dump-autoload -a
(-a 等同于 --classmap-authoritative)
原理
執行這個命令隱含的也執行了 Level-1 的命令, 即同樣也是生成了 classmap,區別在于當加載器在 classmap 中找不到目標類時,不會再去文件系統中查找(即隱含的認為 classmap 中就是所有合法的類,不會有其他的類了,除非法調用)
注意事項
如果你的項目在運行時會生成類,使用這個優化策略會找不到這些新生成的類。
第二層級(Level-2/B)優化:使用 APCu cache
執行命令:
執行命令 composer dump-autoload --apcu
原理:
使用這個策略需要安裝 apcu 擴展。
apcu 可以理解為一塊內存,并且可以在多進程中共享。
這種策略是為了在 Level-1 中 classmap 中找不到目標類時,將在文件系統中找到的結果存儲到共享內存中, 當下次再查找時就可以從內存中直接返回,不用再去文件系統中再次查找。
在生產環境下,這個策略一般也會與 Level-1 一起使用, 執行composer dump-autoload -o --apcu, 這樣,即使生產環境下生成了新的類,只需要文件系統中查找一次即可被緩存 , 彌補了Level-2/A 的缺陷。
如何選擇優化策略?
要根據自己項目的實際情況來選擇策略,如果你的項目在運行時不會生成類文件并且需要 composer 的 autoload 去加載,那么使用 Level-2/A 即可,否則使用 Level-1 及 Level-2/B是比較好的選擇。
幾個提示
Level-2的優化基本都是 Level-1 優化的補充,Level-2/A 主要是決定在 classmap 中找不到目標類時是否繼續找下去的問題,Level-2/B 主要是在提供了一個緩存機制,將在 classmap 中找不到時,將從文件系統中找到的文件路徑緩存起來,加速后續查找的速度。
在執行了 Level-2/A 時,表示在 classmap 中找不到不會繼續找,此時 Level-2/B 是不會生效的。
不論那種情況都建議要開啟 opcache, 這會極大的提高類的加載速度,我目測有性能提升至少 10倍。
以上是“composer autoload自動加載性能優化的示例”這篇文章的所有內容,感謝各位的閱讀!希望分享的內容對大家有幫助,更多相關知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。