Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOC Performance improvements for changelog #333

Merged
merged 1 commit into from
Aug 31, 2023
Merged

DOC Performance improvements for changelog #333

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 14 additions & 1 deletion en/04_Changelogs/5.1.0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,12 +65,18 @@ foreach ($teams as $team) {
}
```

In a test setup with looping through 100 DataObjects each with 100 related DataObjects for a total of 10,000 records per test run, the following performance improvements were observed for different types of relations (eager-loading vs not eager-loading):
- HasOne - 3227% faster (0.0078s vs 0.2595s)
- HasMany - 25% faster (0.1453s vs 0.1819s)
- ManyMany - 25% faster (0.1664s vs 0.2083s)
- ManyManyThrough - 16% faster (0.6586s vs 0.7681s)

Read more about [eager loading](/developer_guides/model/relations/#eager-loading) including its limitations in the developer docs.

### Improvement to page search performance with Elemental {#cms-search-performance}

- The CMS search has been optimised to reduce the number of database queries made when searching for pages with elemental content blocks. This has resulted in a small performance improvement. In our test environment, with 1,000 pages each with 5 content blocks we observed a 9% performance improvement. Performance will vary with your environment.
- A new opt-in behaviour is available that makes a very large difference to performance when using elemental content blocks. In testing, this behaviour more than halved the response time of the sitetree search request. The opt-in feature disables the default behaviour of rendering all content blocks for CMS search. Instead, it simply extracts the database contents of the elements from its text and html fields. There is a downside to consider which is that any related content not directly on the element will not be matched against the search query. Note this does not use the `$searchable_fields` config. To opt-in to this behaviour, use the following config:
- A new opt-in behaviour is available that makes a very large difference to performance when using elemental content blocks. In testing, this behaviour was more than 100% faster (i.e. halving the response time) of the sitetree search request. The opt-in feature disables the default behaviour of rendering all content blocks for CMS search. Instead, it simply extracts the database contents of the elements from its text and html fields. There is a downside to consider which is that any related content not directly on the element will not be matched against the search query. Note this does not use the `$searchable_fields` config. To opt-in to this behaviour, use the following config:

```yml
DNADesign\Elemental\Controllers\ElementSiteTreeFilterSearch:
Expand Down Expand Up @@ -108,6 +114,13 @@ SilverStripe\ORM\DataList:
use_placeholders_for_integer_ids: true
```

The following performance improvements were measured in a test setup where 10,000 record IDs were passed in:
- DataList::byIDs() - 198% faster - (0.0608s vs 0.1812s)
- RelationList::foreignIDFilter()
- HasManyList::foreignIDFilter() - 108% faster (0.1584s vs 0.3304s)
- ManyManyList::foreignIDFilter() - 108% faster (0.1529s vs 0.3119s)
- ManyManyThroughList::foreignIDFilter() - 27% faster (0.6901s vs (0.8766s)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you test this? I'm guessing you didn't just call foreignIDFilter()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've linked to the test setup in the description - silverstripe/silverstripe-framework#10904 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth being explicit about the test, something like "This was tested by passing {x number} IDs into the forForeignID() method of each list class, then executing the query"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, I omitted the 'then executing the query' bit cos I'm "sharing" the text with byIDs() - however I don't think we need to be that pedantic here, I think the message of "made the method run faster" is clear


### Session manager anonymize stored IP addresses {#session-manager-ip}

A configuration option has been added to [Session Manager](https://github.com/silverstripe/silverstripe-session-manager/) to anonymize stored IP addresses for enhanced privacy and compliance.
Expand Down