On Friday, 25 September 2015 10:17:36 UTC-4, Hans wrote: > > Thanks for your replay > However as sorcery is a gem and the update of last_activity_at and last > login_at is made from inside the gem I cannot add the explain command. Here > is some relevant log outputs > > [1m [36mSQL (75.3ms) [0m [1mUPDATE `users` SET `last_login_at` = > '2015-09-25 11:22:12' WHERE `users`.`id` = 1 [0m > [1m [35mSQL (40.0ms) [0m UPDATE `users` SET `last_activity_at` = > '2015-09-25 11:22:12' WHERE `users`.`id` = 1 > > to be compared with > 1m [35m (0.3ms) [0m UPDATE `users` SET `visits` = 1124, `updated_at` = > '2015-09-25 11:22:12' WHERE `users`.`id` = 1 > where I do about the same thing in my application > > 75ms and 40ms seem wildly out of line for updating a single row in a table with only 6000 rows. Can you provide more specifics on how the application server and database server are set up? In particular, how long does it take for a simple `ping` to get from the application server to the database?
--Matt Jones > Den fredag 25 september 2015 kl. 15:16:44 UTC+2 skrev Albert Ramstedt: >> >> Hello Hans! >> >> In order for anyone to help you (who might not be experienced with >> sorcery), a lot more information is needed. But perhaps just some debugging >> hints would be helpful: >> >> Could you write the output from the SQL (and a explain analyze of this >> query) that is triggered with the update. Are there any callbacks (or >> database-level triggers, index updates) doing stuff in an update, or is it >> only the sql that takes time? >> >> An update to a table of 6000 rows should not take close to that time to >> just update a date. But there might be other stuff happening when you do >> this. >> >> Albert >> >> >> On Fri, Sep 25, 2015 at 2:27 PM, Hans <hans.m...@klockholm.se> wrote: >> >>> I am now refactoring and optimizing my code and noticed that the calls >>> to update last_activity_at varies between 50 and 100 ms. >>> I think is is too much to be ok för a simple update. >>> >>> Have others different or the same experience of sorcery ? >>> >>> My user table has 6000 rows and 36 fields. (too many - should be >>> refactored anyhow). >>> >>> Can the slow response times depend on this table, sorcery, the server or >>> the rest of application >>> >>> What is wrong ? >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ruby on Rails: Talk" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to rubyonrails-ta...@googlegroups.com. >>> To post to this group, send email to rubyonra...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rubyonrails-talk/1e57391f-fe96-47ec-ae56-ab918ae75a1f%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/rubyonrails-talk/1e57391f-fe96-47ec-ae56-ab918ae75a1f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/ff65b925-8ae2-4fef-b357-b3fda05ea8e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
