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

Translation Plugin Performance with Cache? #241

Closed
mkormendy opened this Issue Sep 5, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@mkormendy

mkormendy commented Sep 5, 2017

I find it interesting regarding this remark:

So, what about using only a translation plugin? This can work, but it's hardly optimal. Every query that comes in needs to be parsed and converted to SQL Server style syntax before it's executed. Yikes!

If the request is translated with a PHP pre-layer before the request is made to the SQL server, and PHP caching is turned on and optimized (which in most cases, you'd be ridiculous to not have), then there's really only a performance hit on the first attempt, and all future translations are already completed and coming from the cache. Surely it isn't as bad as forewarned and more maintainable.

@patrickebates

This comment has been minimized.

Show comment
Hide comment
@patrickebates

patrickebates Sep 5, 2017

Member

Might want to have a quick look at our backstory
http://projectnami.org/how-did-we-get-here/
We spent months working with what was at the time (and I believe still is, though not updated) the best translation plugin and simply couldn't make it work completely with just WP Core. Our decision over four years ago to create this fork was not taken lightly, or without considering all other options. Eventually we even incorporated elements of that translation plugin into PN in order to handle basic translation for plugins.

While you are correct that caching will minimize the translation hit for the public, it doesn't help with users who are currently logged in. And for larger sites, we have experienced that it's a significant amount of load.

As for maintainability, I can tell you that keeping up with changes in WP Core has become a pretty straightforward process. Much, much easier than trying to keep the translation layer updated for annoying plugins which insist on making direct DB calls even when the core API already handles it (Jetpack, I'm looking at you...).

Member

patrickebates commented Sep 5, 2017

Might want to have a quick look at our backstory
http://projectnami.org/how-did-we-get-here/
We spent months working with what was at the time (and I believe still is, though not updated) the best translation plugin and simply couldn't make it work completely with just WP Core. Our decision over four years ago to create this fork was not taken lightly, or without considering all other options. Eventually we even incorporated elements of that translation plugin into PN in order to handle basic translation for plugins.

While you are correct that caching will minimize the translation hit for the public, it doesn't help with users who are currently logged in. And for larger sites, we have experienced that it's a significant amount of load.

As for maintainability, I can tell you that keeping up with changes in WP Core has become a pretty straightforward process. Much, much easier than trying to keep the translation layer updated for annoying plugins which insist on making direct DB calls even when the core API already handles it (Jetpack, I'm looking at you...).

@mkormendy

This comment has been minimized.

Show comment
Hide comment
@mkormendy

mkormendy Sep 5, 2017

Jetpack of all plugins is by principal the worst offender being the child of Automattic itself in this case .. I do make DB calls of my own directly with my plugins, but since I maintain them internally, I would likely write the equivalent translation with automatic choice.
I'm considering using SQL Server because it has some performance gains over MariaDB that I prefer and my office is primarily a MS software house. The B.I. people hate writing queries for MySQL.

mkormendy commented Sep 5, 2017

Jetpack of all plugins is by principal the worst offender being the child of Automattic itself in this case .. I do make DB calls of my own directly with my plugins, but since I maintain them internally, I would likely write the equivalent translation with automatic choice.
I'm considering using SQL Server because it has some performance gains over MariaDB that I prefer and my office is primarily a MS software house. The B.I. people hate writing queries for MySQL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment