Changing and saving a project is slow

[BartChris]

Describe the bug
Changing the title of a project or setting it to active or inactive is slow. And it seems as if it gets slower the bigger the project is (more processes, more templates). When the project has only a handful of processes i notice no real slowdown.

To Reproduce
Steps to reproduce the behavior:

1. Go to the edit page of the project
2. Change its name or make it inactive
3. Save

Expected behavior
Editing and saving a project should be faster.

Release
Kitodo 3.9, Main (have not encountered that on 3.8 yet, in my tests 3.8 is fast here)

[BartChris]

Checking the executed SQL statements a little bit reveals that changing the name of a super small project (one process) issues only a handful of sql, but changing data in a bigger projects (3000 processes) does hundreds of sql queries.

Relevant code:

kitodo-production/Kitodo/src/main/java/org/kitodo/production/forms/ProjectForm.java

Line 229 in 585a468

public String save() {

Most queries stem from the actual save call

kitodo-production/Kitodo/src/main/java/org/kitodo/production/forms/ProjectForm.java

Line 238 in 585a468

ServiceManager.getProjectService().save(project);

which probably indicates that the annotations in Project.java lead to a lot of side effect queries.

[BartChris]

Changing

kitodo-production/Kitodo-DataManagement/src/main/java/org/kitodo/data/database/beans/Project.java

Lines 101 to 102 in 585a468

	@OneToMany(mappedBy = "project", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
	private List<Process> processes;

to

@OneToMany(mappedBy = "project", cascade = CascadeType.PERSIST, orphanRemoval = true, fetch = FetchType.LAZY)
    private List<Process> processes;

fixes the issue for me. What was the reason for introducing CascadeType.ALL here @matthias-ronge?

Edit: Sorry, i saw that it was ALL also in 3.8. but somehow it only has this bad effects in 3.9+.

[BartChris]

OK, i think i know what happens. Changing anything in the project title (or in the active state or any other project property) requires reindexing every associated process in Elasticsearch because we index the project title in the process documents in Elasticsearch (only in the catch all fields, since normal project search is done in SQL). This could mean that thousands of processes get reindexed immediatly.

[henning-gerhardt]

I can confirm this behaviour that on any changes inside the project all processes of the changed project get re-indexed. As I can not open an project with hundred thousand processes assigned (I will open a new issue for this later) I will not really know how long this will take time that after a change this project get saved and all processes are re-indexed.

[BartChris]

#6779 also seems to effect this in a positive way. But i suppose reindexing still happens? But maybe in the background?

Edit: It seems you have to reindex the processes by hand now, to have the project name change reflected in the index and be able to search for it without prefix (search over all fields))

[henning-gerhardt]

#6779 also seems to effect this in a positive way. But i suppose reindexing still happens? But maybe in the background?

Edit: It seems you have to reindex the processes by hand now, to have the project name change reflected in the index and be able to search for it without prefix (search over all fields))

I can confirm this "new" behaviour too:

• Without [3.9] Fix hasProcesses lookup and improve ProjectForm performance #6779 applied storing a changed project takes a long time as in background all assigned processes are re-indexed.
• With [3.9] Fix hasProcesses lookup and improve ProjectForm performance #6779 applied opening and storing a project is now fast but the data from project (only project title) in the search index is not updated until the process is save in some way.

I did not expect this changed behaviour on applying #6779 as only a value for a boolean flag was changed from a list operation over all retrieved processes to a strict database query. This is strange.

[BartChris]

I think the reason is that in the old code Hibernate, when loading the project form, loads all processes as well. Since the project is changed all the associated entitites are considered dirty and have to be re-indexed again. When using the database-only approach Hibernate does not register associated processes as dirty, so does not see a reason to re-index.
I suppose this also has to do with the fact that we do not use e.g. an @IndexEmbedded annotation which would register such changes automatically, but have a more manual indexing strategy.

[BartChris]

When #6778 is merged i consider this issue solved as well. The fact that no re-indexing happens automatically is a seperate issue. Re-indexing happened only by accident because of (non intentionally) bringing in all processes when opening the project form, which leads to terrible performance.