-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Performance impact on "save_post" actions #48
Comments
Hi Alexander. Thanks for your report. I already created a ticket in our internal tracking system to review and address this issue. For reference, it is named wpmlbridge-300 I will update here once we have a suitable solution, or at least some news to share. Regards. |
decodekult
added a commit
that referenced
this issue
Jul 4, 2024
- Avoid multiple checks on index name existance on multiple processes. #48
decodekult
added a commit
that referenced
this issue
Jul 4, 2024
- Avoid multiple checks on index name existance on multiple processes. #48
decodekult
added a commit
that referenced
this issue
Jul 4, 2024
- Avoid multiple checks on index name existance on multiple processes. #48
decodekult
added a commit
that referenced
this issue
Jul 10, 2024
- Avoid multiple checks on index name existance on multiple processes. #48
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This plugin appears to have a major performance impact when saving posts. This is caused by multiple remote requests to the ElasticSearch endpoint. For each language, there are two calls to
index_exists
and one call tobulk_index
. In our case, this results in 12 (!) remote calls, each costing around 500ms of loading time.I understand the need for calling
bulk_index
for each language, butindex_exists
should not be called this often, or its result should be cached. All the calls toindex_exists
appear to be caused byWPML\ElasticPress\Sync\Singular::manageSyncQueue
. With wpml-elasticpress disabled, this endpoint is not called at all when saving a post.I appreciate you looking into this, as our editors are complaining about slow performance when they are working in wp-admin.
The text was updated successfully, but these errors were encountered: