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

cache the language files in one big file (Trac #2877) #2877

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 13 comments
Closed

cache the language files in one big file (Trac #2877) #2877

elgg-gitbot opened this issue Feb 16, 2013 · 13 comments

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/2877 on 41109860-03-27 by trac user coldtrick, assigned to cash.

Elgg version: 1.7

One of our clients had a lot of performance issues on their Elgg 1.7.1 installation.
After we did some research we found that the loading of languages takes up a lot of time.

We decided to cache the loaded languages in one large file (per language) and this decreased the loading time of pages by 30%-50%.

To test that there is a problem load the core language file 100 times. All the time goes into add_translation, since this is an array merging.

As the languages on a running site don't change (all that much) why not cache them like simplecache.

Attached you'll find a file how we did it on an Elgg 1.7.1 installation. It isn't the nicest code but it should give a direction, and it works.

@elgg-gitbot
Copy link
Author

Attachment added by trac user coldtrick on 41109861-05-06: languages.php

@elgg-gitbot
Copy link
Author

brettp wrote on 41110567-04-11

Thanks for taking the time to research this. I've attached a patch file for only the changes.

Looking at how you're storing the file, did you find that your method of storing the file by creating actual PHP code is faster than serializing the array?

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.1 by brettp on 41110567-04-11

@elgg-gitbot
Copy link
Author

Attachment added by brettp on 41110573-03-14: 2877_languages.patch

@elgg-gitbot
Copy link
Author

trac user coldtrick wrote on 41110575-01-14

we made it a PHP file so that we could use the core functions to read the language in the file.

we didn't check if there was a better way to store it.

@elgg-gitbot
Copy link
Author

ewinslow wrote on 41973544-07-15

Interested in this. Caching the final array seems like a very good idea.

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.3 by cash on 41975837-12-23

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.4 by cash on 42004287-02-22

@elgg-gitbot
Copy link
Author

trac user sembrestels wrote on 42036582-03-31

Each language should be loaded when it is necessary.

Usually only one language per page is needed, sometimes more, when you use the third parameter of elgg_echo, but not all languages per page.

Doing a cache per language and loading it when it is needed will improve performance a lot.

@elgg-gitbot
Copy link
Author

cash wrote on 42036676-09-16

I agree that we should have one file per language.

@elgg-gitbot
Copy link
Author

trac user coldtrick wrote on 42038045-08-19

Replying to sembrestels:

Each language should be loaded when it is necessary.

Usually only one language per page is needed, sometimes more, when you use the third parameter of elgg_echo, but not all languages per page.

Doing a cache per language and loading it when it is needed will improve performance a lot.
On one page you can have three active languages:

  1. User language (eg 'nl')
  2. Site language (eg 'fr')
  3. Elgg fallback language 'en'

As stated in the start of this ticket you should have one file per language.

@elgg-gitbot
Copy link
Author

cash wrote on 42096625-01-09

Merge pull request #156 from cash/cache_lang

Fixes #2877 Adds language string caching to system cache
Changeset: 601ec5c

@elgg-gitbot
Copy link
Author

cash wrote on 42422630-01-30

Merge pull request #156 from cash/cache_lang

Fixes #2877 Adds language string caching to system cache
Changeset: 601ec5c

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

No branches or pull requests

1 participant