Closed fredericalpers closed 1 year ago
@dai-eastgate @yeneastgate please work on this issue with the highest priority.
@fredericalpers Yes, we will fix it as soon as possible.
@fredericalpers I have checked the “addFieldsAddressEstateWithRegionValues” function and found out that it is used to pass field type from “multiple select” to “single select” by calling API
See the attached file:
Therefore, this issue occurs for customers that have many (hundreds or maybe thousands) of regions (regionaler_zusatz). We will continue working to find suitable solution for better performance and more optimized.
So:
For the “Custom Labels Estates” feature, we can delete the “addFieldsAddressEstateWithRegionValues” function
For the “Default value for form” feature: we must keep it ( which must be used for the “Default value for estate list” feature that we are implementing https://github.com/onOffice-Web-Org/oo-wp-plugin/pull/494)
For the “Filterable for estate list” feature: we must also keep it.
Please have a check again and let us know your opinion on our research?
Thanks for analysing @yeneastgate SorryI don't get it, why is this addFieldsAddressEstateWithRegionValues call necessary here in getFieldLabel? I removed it local and still get custom labels of my fields.
For a hotfix please remove it. And maybe we don't need it anyway here?
Thanks for analysing @yeneastgate SorryI don't get it, why is this addFieldsAddressEstateWithRegionValues call necessary here in getFieldLabel? I removed it local and still get custom labels of my fields.
For a hotfix please remove it. And maybe we don't need it anyway here?
I have checked, the function "addFieldsAddressEstateWithRegionValues" is only used to call Region Values and not related to custom labels. I will create a hotfix for this issue
@fredericalpers @andernath I fixed this issue:
Please review our code and test this issue again.
One more point, it would be great if you could provide us with the test environment which has “a large to very large database (3.87GB up to 41.80GB)” so that we could check the issue correctly. Thanks!
@fredericalpers @andernath I fixed this issue:
For the “Custom Labels Estates” feature, I have deleted the “addFieldsAddressEstateWithRegionValues” function. => But the “Custom Labels Estates” feature still work well See the attached video:
hotfix.mp4
- For the “Default value for form” and "Filterable for estate list" feature: we must keep it => I have tested those features at the time and they still work well
Please review our code and test this issue again.
One more point, it would be great if you could provide us with the test environment which has “a large to very large database (3.87GB up to 41.80GB)” so that we could check the issue correctly. Thanks!
We are currently reviewing and testing. Also we are waiting for our IT Department to set up a new database with a larger database. Unfortunately the import is not finished yet. We will be able to give you more feedback tomorrow.
Current state
We have received an increasing number of complaints about performance problems with the plugin.
Both external and internal pages with content of the plugin (mostly property pages) are onwards from version 4.7 significantly slower compared to version 4.6. Change log can be viewed here.
It is noticeable that all customers tested so far have a large to very large database (3.87GB up to 41.80GB). (Screenshots comparing the performance attached)
Investigate
Analysis of the bug on https://46.onofficeweb.com/immobilien/
There seem to be changes for the Custom Labels Estates feature in EstateList.php getFieldLabel($field) from version 4.7. responsible for the poor performance.
In the
EstateList.php getFieldLabel($field)
method,FieldsCollectionBuilderShort .addFieldsAddressEstateWithRegionValues()
is called since this version. Commenting out this line, we can't see any performance issues anymore.addFieldsAddressEstateWithRegionValues
has been around for over a year, but has not been called in getFieldLabel until now. The aim is to find out why this function generates such a large performance loss, and then to find a suitable solution.Desired state
The performance should be at least as "good" as version 4.6, preferably better and more optimized.