Investigate performance impact of large number of groups
- Dominant language
- No language data
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
> Issues on Github are meant for bug reporting. Please post feature requests on the [discussion forum](https://discuss.flarum.org/t/features).
---
> Try to complete the below form as far as you are able and are willing to share. Add a screenshot of the issue if you can.
## Explanation
Flarum has been chosen to be the adopted base software by our client for a modified forum-esque platform. As we were hacking our way through the system to make it work the way we needed it, we built it into a docker container. After much frustration with load times taking immensely long amounts of time we started doing some monitoring and logging of operations. We found that for a single page load ~1600 operations to check permissions happen. This is just one aspect of the application and even running on a task given a full vCPU core and a gigabyte of RAM it still takes about 10 seconds to load.
Are there ways to increase performance on this? I think the ideal fix would be to change the way permissions are checked but I think it may be because our use case has strayed a little from the intended platform that this issue is occurring. Would I be correct in stating that the goal of flarum is to have the app load all the data from the 'api' php backend once and then not have to do it again unless absolutely necessary?
## Technical details
- Version of Flarum: 0.1.0-beta.7
- Website URL where the bug is visible: n/a
- The webserver you are running: apache
- PHP version: 7.0
- Hosted environment: ECS
- Hosting provider: AWS
## Flarum info
```
n/a
```
## Log files
```
n/a
```
Contributor guide
Research direction
No source files or tests are named. Start by profiling a representative page load and the permission checks that account for about 1,600 operations, then compare this with the reported 10-second load on PHP 7.0 in the ECS environment. Done means identifying the performance bottleneck and documenting a concrete, reproducible direction for improvement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- apache, aws, docker, php
- Domain
- authorization, backend, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100