我最近研究分析了在 SWIS上面創建的項目的性能。令人驚訝的是，最耗費性能的方法之一是優秀的 spatie/laravel-permission 包造成的。

經過查閱更多資料和研究，發現一個可能明顯改善的性能問題 。既然解決方案已明確闡述，就很容易編寫代碼改善，提交請求。

現在這個解決方案已被合并和發布，下面是這個性能問題的分析和如何在自己的項目避免這類問題。

TL;DR: 跳轉到結論部分.

如果我們抽象的看 spatie/laravel-permission 它主要做兩件事：

保持一個屬于某個模型的權限清單。

檢查某個模型是否具有權限。

第一點說是性能瓶頸有點牽強。這里的權限數據存放在數據庫中，需要的時候將會被讀取出來。這個過程是有點慢但也只是執行一次。結果會被緩存下來，后續的請求可以直接使用。

第二點在性能瓶頸的觀點上來看確實是一個瓶頸。 這個瓶頸取決于權限的性質和項目的大小， 因為權限會被頻繁的檢查。 在這個檢查的過程中任何的遲鈍都會成為整個項目的性能瓶頸。

過濾權限集合的方法被認為是造成低性能的原因。 它做了如下事情：

$permission = $permissions - where( id , $id) - where( guard_name , $guardName) - first();

修改后：

$permission = $permissions - filter(function ($permission) use ($id, $guardName) { return $permission- id === $id $permission- guard_name === $guardName; - first();

這兩個代碼段實現了同一件事情，但第二個更快。

我正在開發的應用中大約有 150 個不同的權限。 在一個普通的請求中， 大約有 50 個權限需要用 hasPermissionTo 這個方法去檢查，當然，有些頁面可能需要檢查大約 200 個權限。

以下是用來做性能測試的一些設置。

$users = factory(User::html' target='_blank'>class, 150)- make();$searchForTheseUsers = $users- shuffle()- take(50);# 方法 1: whereforeach($searchForTheseUsers as $user) { $result = $users- where( id , = , $user- id)- first();# 方法 2: 過濾，傳遞一個模型作為回調foreach($searchForTheseUsers as $searchUser) { $result = $users- filter(function($user) use ($searchUser) { return $user- id === $searchUser-  })- first();# 方法 3: 過濾，傳遞屬性作為回調foreach($searchForTheseUsers as $user) { $searchId = $user-  $result = $users- filter(function($user) use ($searchId) { return $user- id === $searchId; })- first();}

以上三個方法都會被用來測試過濾 1 個屬性，2 個屬性，3 個屬性，所以，用方法 1 過濾三個屬性就會是這樣：

foreach($searchForTheseUsers as $user) { $result = $users - where( id , = , $user- id) - where( firstname , = , $user- firstname) - where( lastname , = , $user- lastname)- first();}

我們可以得出結論：對一個項目而言，重復的過濾一個大集合會引發嚴重性能瓶頸。

多屬性的過濾明顯增加計算成本。

使用 Collection::filter() 代替 Collection::where() 可以提高60%的性能。

警告：傳遞完整的模型給過濾器回調是很耗費性能的，最好是傳遞單獨的屬性。

以上就是本文的全部內容，希望對大家的學習有所幫助，更多相關內容請關注PHP ！

相關推薦：

在Laravel 5.6中 使用Swoole的協程數據庫查詢

Laravel 的 Facade 外觀系統的分析

laravel+Redis簡單實現隊列通過壓力測試的高并發處理

以上就是對 Laravel-permission 項目的性能優化的詳細內容，PHP教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。