> Marnen Laibow-Koser wrote: >> Frank Poo wrote: >>> The query is just an UPDATE with a COALESCE keyword in it. All it >>> does >>> is increment counters: >>> >>> UPDATE `statistics_api` SET `count_request` = >>> COALESCE(`count_request`, >>> ?) + ? WHERE (`id` = ?) >>> >>> This one took 8,553 ms according to New Relic. The weird part is >>> that >>> there is an index on 'id' (as well as a few other columns) on this >>> table. I just can't figure out why the query's taking so long ... >> >> 8.5 seconds? For that?!? You might want to ask someone who knows >> more >> about mySQL configuration than I do, but clearly your DB setup has >> problems. If you run that query when your DB is not otherwise >> being hit >> by your app, how long does it take? >>
> Frank Poo wrote: > This query is lightning fast when my server is NOT under load. Just > dead > slow when I'm seeing a lot of load. You're right, the first > placeholder > is probably redundant.. That would likely indicate that the DB is pretty dern busy fulfilling reads (though someone should analyse that to prove it). When doing this kind of logging it often becomes necessary to have a second database which is optimized for writes to take the continual updates so that your read/write-infrequent data set is left alone. Those log writes should also be fired off as an asyncronous task so that the rest of the page/request is not slowed down waiting for the write to occur. I agree that yanking the DB in favor of in-memory workload doesn't seem appropriate yet. -- def gw writes_at 'www.railsdev.ws' end --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
