Translation Script v2.18 Bugfixes - Page 3

davesnake · 24 June, 2009, 20:32 PM

Quote:

Originally Posted by Will.Spencer

It seems that CMS-based translation engines are a much easier solution architecturally, they avoid so many complexities that come with generic full-page translators.

Plus, the MySQL data storage is quite interesting!

Turns out MySQL cannot handle the big sites, read/write access becomes way too slow.

Were looking at txt file caching like your script now Will, that should be fine speed wise and with the API, no blocking.

Still have the disk space issues, lol. This is a tough cookie to crack.

Will.Spencer · 25 June, 2009, 11:21 AM

Have you looked at caching the MySQL requests instead?

davesnake · 25 June, 2009, 11:28 AM

Something like memcached? One of my coders thinks we should use that on it's own, no MySQL whatsoever... I love to hear your thoughts Will...

Will.Spencer · 25 June, 2009, 11:59 AM

I think the MySQL data storage was an inspired idea and I would not give up on it so quickly.

MySQL optimization is a bit of a specialty though, so you may need to bring in a specialist DB/coder.

davesnake · 25 June, 2009, 12:01 PM

Finding someone is easier said than done.

davesnake · 25 June, 2009, 12:16 PM

Another problem is Will everyone has a different opinion, you should do this but you need to get someone else to do it, that someone else says no, you need to do it like this... If I'm honest I'm 5 mins away from canning everything.

Will.Spencer · 25 June, 2009, 14:51 PM

Software development is frustrating as heck.

For MySQL tuning, I highly recommend the two scripts listed in this thread: MySQL Performance Tuning Primer Script