摘要:我最近研究分析了在上面創建的項目的性能。經過查閱更多資料和研究,發現一個可能明顯改善的性能問題。在這個檢查的過程中任何的遲鈍都會成為整個項目的性能瓶頸。過濾集合類過濾權限集合的方法被認為是造成低性能的原因。使用代替可以提高的性能。
我最近研究分析了在?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::class, 150)->make(); $searchForTheseUsers = $users->shuffle()->take(50); # 方法 1: where foreach($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->id; })->first(); } # 方法 3: 過濾,傳遞屬性作為回調 foreach($searchForTheseUsers as $user) { $searchId = $user->id; $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(); }結果
方法 #1 | 方法 #2 | 方法 #3 | |
---|---|---|---|
1個屬性 | 0.190 | 0.139 (-27%) | 0.072 (-62%) |
2個屬性 | 0.499 | 0.372 (-25%) | 0.196 (-61%) |
3個屬性 | 0.488 | 0.603 (+25%) | 0.198 (-59%) |
我們可以得出結論:對一個項目而言,重復的過濾一個大集合會引發嚴重性能瓶頸。
多屬性的過濾明顯增加計算成本。
使用 Collection::filter() 代替?Collection::where() 可以提高60%的性能。
警告:傳遞完整的模型給過濾器回調是很耗費性能的,最好是傳遞多帶帶的屬性。
致謝感謝 Spatie 和 spatie/laravel-permissions?的貢獻者創建如此優秀的包,我非常喜歡使用!感謝 Andru Beldie?指出這些性能問題,我才有機會對其進行調查和糾正。
鏈接spatie/laravel-permission package.
Issue #550 addressing performance problem.
Pull request #710 that fixes problems.
更多現代化 PHP 知識,請前往 Laravel / PHP 知識社區
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/28808.html
摘要:在大多數的開發中,角色和權限的管理都是非常重要的一部分。上關于角色和權限管理的包有很多,今天就為大家介紹幾個好用的包。緩存在中,為了提高應用的性能,或自動的存儲角色和權限數據。 showImg(https://segmentfault.com/img/bVTEb3?w=2200&h=1125); 在大多數的web開發中,角色和權限的管理都是非常重要的一部分。Laravel上關于角色和權...
摘要:初步分析提升可從兩方面入手,一個是增加并發數,其二是減少平均響應時間。大部分的時間花在系統與數據庫的交互上,到這,便有了一個優化的主題思路最大限度的降低平均響應時間。不要輕易否定一項公認的技術真理,要拿數據說話。 本文最早發表于個人博客:PylixmWiki 應項目的需求,我們使用tornado開發了一個api系統,系統開發完后,在8核16G的虛機上經過壓測qps只有200+。與我們當...
摘要:手頭做的項目開發得差不多了,而打包配置是一開始粗略配置的,不大的項目打包出來得,所以現在必須進行優化。用于生產環境的打包,設置其為后,這些庫會提供最小體積的文件。這種情況打包后的體積要更小一些。最后打包結果的體積開銷主要就是以上幾項。 手頭做的項目開發得差不多了,而打包配置是一開始粗略配置的,不大的項目打包出來得6MB+,所以現在必須進行優化。 打包結果分析 執行命令 webpack ...
摘要:記錄一個前端項目優化的路程,效果如上圖。第二步優化結果再次運行查看項目打包情況可以看到項目體積已經優化到,中也看不到的蹤影了。本文主要想提供一些優化思路及手段,即如何定位通過,查看頁面加載時間問題,然后再解決這些問題。 showImg(https://segmentfault.com/img/bVbq282?w=381&h=384); 記錄一個前端項目優化的路程,效果如上圖。 接下來我...
摘要:記錄一個前端項目優化的路程,效果如上圖。第二步優化結果再次運行查看項目打包情況可以看到項目體積已經優化到,中也看不到的蹤影了。本文主要想提供一些優化思路及手段,即如何定位通過,查看頁面加載時間問題,然后再解決這些問題。 showImg(https://segmentfault.com/img/bVbq282?w=381&h=384); 記錄一個前端項目優化的路程,效果如上圖。 接下來我...
閱讀 2043·2021-09-07 10:14
閱讀 1478·2019-08-30 15:53
閱讀 2270·2019-08-30 12:43
閱讀 2861·2019-08-29 16:37
閱讀 754·2019-08-26 13:29
閱讀 2000·2019-08-26 13:28
閱讀 437·2019-08-23 18:33
閱讀 3500·2019-08-23 16:09