massive concurrency to tables from busy app
Closed this issue · 6 comments
Are there further optimizations that can be made to code or schema to support high concurrency for copycat_translations lookups. We're seeing some latency to the database table at high concurrency.
Thanks.
We haven't implemented anything yet. The obvious new feature would be that you can enable caching of lookups with, say, 5 minute expiration.
As a current workaround, one pattern we use is to enable copycat only on staging server. Use it to edit copy there, and then export the yml, commit that to the git repository, and deploy to production. On production you can't edit keys, it gets them from the yml.
You can make a feature request (or pull request) for the caching.
On Apr 4, 2013, at 12:31 PM, dfuentes77 wrote:
Are there further optimizations that can be made to code or schema to support high concurrency for copycat_translations lookups. We're seeing some latency to the database table at high concurrency.
Thanks.
—
Reply to this email directly or view it on GitHub.
We are also having big problems in production with latency/concurrency. Since this is all deployed to production already including the mL file, how I get it to stop using the database and only use the yam file? Remove the copycat get from our Gemfile and deploy that?
@jonmarinello Yes, you should just be able to download the latest yaml file(s), remove copycat, and everything should work as before.
I think you need to commit the en.yml to the git repository as well.
Right, Already did that and it works fine. For us at least I don't see much of a win for keeping it in staging. We'll just use the yml fie going forward.
Forgot to say, thanks for getting back to me so quickly. 👍