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.

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 #322

Closed
sboisvert opened this issue Dec 21, 2015 · 4 comments
Closed

Performance #322

sboisvert opened this issue Dec 21, 2015 · 4 comments

Comments

@sboisvert
Copy link
Contributor

CAP is often slow, with the sql queries in https://github.com/Automattic/Co-Authors-Plus/blob/master/co-authors-plus.php#L568
https://github.com/Automattic/Co-Authors-Plus/blob/master/co-authors-plus.php#L695
https://github.com/Automattic/Co-Authors-Plus/blob/master/co-authors-plus.php#L634

We should enable

// Use simple tax queries for CAP to improve performance
add_filter( 'coauthors_plus_should_query_post_author', '__return_false' );

by default
And do the backfilling of
$ wp co-authors-plus create-terms-for-posts
as a one time cron fix.
We should enable the ability to disable this (with a filter). And it should run automatically when the plugin is updated and when activated.
The plugin should also be profiled and other performance enhancements added where it would make sense to.

@mjangda
Copy link
Member

mjangda commented Dec 21, 2015

Enabling by default might be an over-optimization since this only impacts large-ish sites (may need data on what the "breaking point" is). Plus, for really large sites, the backfill command takes a long time so I'm not sure using cron is a good idea.

In #319, I suggested adding better documentation for this instead.

@sboisvert sboisvert added this to the 3.2 milestone Dec 22, 2015
@sboisvert
Copy link
Contributor Author

Doing #180 instead might be good. that one is not the only slow query. Author pages can get really slow as well.

@mattoperry
Copy link
Contributor

since #180 is added to 3.2, I'll remove this issue from that milestone for now. We should continue to look for specific slowness though, and open additional issues.

@mattoperry mattoperry removed this from the 3.2 milestone Jan 15, 2016
@philipjohn
Copy link
Contributor

Closing in favour of specific performance issues that can be directly addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants