Web performance with the new version of the module

[yako1984]

Hello, since version 2.0.16.48 the module slows down the web a lot. In version 2.0.16.48 the web is fluid and fast, but with the new version the web becomes slow.

[hartenthaler]

There are no features in the releases 2.0.16.48, 49 or 50 that have a significant influence on the performance. Introducing the possibility to filter the results (only dead male individuals for example) in release 45 had an influence because all combinations of filter options have to be prepared if this function is used (needs about 10 times more CPU time), but I cannot observe this; in my experience, the module is still very fast in execution. Have you activated other modules at the same time? For example, the Vesta modules have a big influence on the response time when you are using many shared hierarchical places. Or can you describe a bit more precisely what you observed when you say "slows down the web a lot"? Opening the tab with the extended family? Using a filter option?

[yako1984]

If I install the module with version 2.0.16.48 the web runs normally (fast), when installing the new version 2.0.16.50 the web loads slower, it shows, I did the test with both versions. Loading is delayed when you open a person's characteristics page. no, do not install another module. It may be my server that is not powerful enough I do not know. But I notice performance difference from one version to another. Tomorrow I continue to test and verify. regards

[hartenthaler]

ok, I will check this, too.

[yako1984]

I have been testing and it is the module that slows me down the web. I don't know if the change in the module structure will have something to do with it, because in x.48 the language is in modules.php and not in x.50. Or if it will be something else, but it is definitely the module.

Look at the video that I attach, with the old module and with the new one and see the loading times:

[TheDutchJewel]

Is this relates with issue #102?

[yako1984]

ok, I test it and I confirm if it works.

[TheDutchJewel]

No, also with removed old versions the problem exists.

But I suspect that the cause of issue #102 is also the cause of this problem.

[hartenthaler]

I just removed the autoload function. Can you check version 2.0.16.51, please? I hope that this solves the performance problem, too.

[TheDutchJewel]

I checked version 2.0.16.51, but the problem is not solved.

To work smoothly with webtrees I have to disable the module, otherwise I have to wait many seconds between actions.

[yako1984]

It is not solved, it is still slow. From my ignorance, I don't know if it has to do with the different structuring of the files.

[hartenthaler]

The idea behind restructuring the very large module file was to separate some functions to have better maintainability. I have to check if this is the reason for the performance problem or if there was another change responsible for this.

[reteP-riS]

I cannot confirm version 50 or 51 being slower than versions 48 and 49, but every situation and configuration may be different. For example I deactivated the chain of partners feature. Could this feature be causing this issue?

[hartenthaler]

The chain of partners is a bit special because it is based on recursion. But the longest partner chains in my tree have about 30 members and normally you will have seldom more than partner of partner of partner. To search these few members in a partner chain is not time-consuming.

[TheDutchJewel]

For example I deactivated the chain of partners feature. Could this feature be causing this issue?

No idea for version 51 because I cannot open the config section of the module: issue #103.

But I tried with version 50 and it's still slows down the operation of webtrees. So disabling the Chain of partners option does not fix the problem.

But clearly, the more people who are part of a section, the longer the wait. For example, for probants with 80 Children of siblings, or 80 Children of siblings or partners.

[yako1984]

I do not know if it is a lot of work, but I would take the x.48 version that is perfect (it is the one I have installed now) I would try to do the restructuring again to see if it works well. I know something basic about python, if I knew about php it would help you without problem.

Or implement the changes one by one and try, in each step to see what creates the error

[hartenthaler]

I just installed Version 48 again and cannot see any performance difference between version 48 and 51.

I checked all modifications, but there were no important modifications besides the refactoring (splitting one file into three files). This was a major change, but I cannot see how this can have an influence on the performance.

There was a small piece of experimental code that should not have an influence on the performance, but who knows! I removed it and released it as 2.0.16.53. Please test with this release.

If it doesn't help: please delete the file module.php and rename the file module1.php to module.php (this file contains all module PHP code in only one file). Maybe this solves the performance problem. I like to try this way first instead of starting again with release 48.

[yako1984]

No, it works slow with the 2 module.php files. I am thinking of a possibility so that you can recreate the error, I will try to solve it, give you temporary access to my server and my ftp. Creating a new website and a user just for you, temporary, so that you can test it on my server and with a copy of my website, you could still find the problem. Tell me if that solution works for you and I get to it. a greeting

[hartenthaler]

That would be great! hermann@hartenthaler.de

[yako1984]

That would be great! hermann@hartenthaler.de

I already sent you the data to the email

[yako1984]

sent you the data to the email

[hartenthaler]

I have now access and can test the performance issue. Thank you @yako1984!

[hartenthaler]

As a first result: I can say that the refactoring in several files is not the problem!

[yako1984]

well! And apart from the refactoring there are many more changes?

[hartenthaler]

No. But one of these changes produces the problem. It is now clear that the problem is in the class "ExtendedFamily" in the file ExtendedFamily.php.

[hartenthaler]

I found it! The reason for this performance bug was a regular expression used to get the labels for children that died STLLBORN or as INFANT. This new feature addressing issue #94 was introduced in V50.

The expression looked like preg_match('/\n1 DEAT((.|\s)*)\n2 AGE STILLBORN/i', $childGedcom, $match) and the problem was "\s" that allows that there are several other records between 1 DEAT and 2 AGE STILLBORN like in

1 DEAT
2 DATE 1 JAN 1900
2 AGE STILLBORN

Now in V54 the search is only based on 2 AGE STILLBORN, not looking after 1 DEAT: preg_match('/\n2 AGE STILLBORN/i', $childGedcom, $match)

Thank you very much for reporting this issue! I did not observe it and would never expect that such a small detail could produce such a performance degradation.

[TheDutchJewel]

New version works fine again. Thank you Hermann!

[yako1984]

good job my friend!

[hartenthaler]

Thank you! Your test installation was very helpful because in your environment it was easy to see which action has an influence on the performance. The tree in my test environment was too small and in my productive system, there are so many other modules installed so that I can't see the effect clearly.