
Each request in development slows down subsequent responses
Reported by Michael Morris | December 9th, 2010 @ 05:14 AM | in 1.1
Requests to the rails stack (with dm-rails, dm-postgres) in development irrespective as to whether a model is queried, cause the next response to be slightly slower.
The problem is exacerbated in larger apps. On a larger app (20 models), we're noticing respones times in dev increase cumulatively by +20msec per/req which adds up very quickly.
I have setup a very barebones app with one model at https://github.com/mtcmorris/dm-problem. No data is required to be in the database - just the existence of a model
To replicate
- Clone, db:create, db:automigrate and start the app.
-
Run @ben_h's schmark which runs many requests against localhost:3000
ruby script/ben-schmark.rb
Over many hunderds of requests, the response time increases. This does not happen with just activerecord leading me to think it is a problem with dm-rails. I've tested with dm-sqlite-adapter and with the postgres adapter - they both exhibit the same result of slowing down the dev environment over time.
Comments and changes to this ticket
-
Xavier Shay December 9th, 2010 @ 04:31 PM
- State changed from new to unconfirmed
- Assigned user set to Xavier Shay
-
Xavier Shay December 9th, 2010 @ 08:39 PM
- State changed from unconfirmed to accepted
- Tag set to dm-rails
The problem is that reloading the models does not reset Model.dependencies, meaning that on every request when the model is reloaded DataMapper::Model.extended is adding a new object to .descendants, causing unchecked growth over time.
I have a hacky fix in my fork:
https://github.com/xaviershay/dm-rails/tree/dev-fix-3.0.xI will test this on our app over the next week, clean it up, then commit to the main repo. Will also bring it up on IRC to see if there are any unintended consequences of clearing out the descendants array.
-
Martin Gamsjaeger (snusnu) December 10th, 2010 @ 10:42 AM
Xavier,
Because you've mentioned the missing set semantics for DescendantSet. I've started work on #1398 and will make sure that it's a set while doing so.
-
Martin Gamsjaeger (snusnu) December 11th, 2010 @ 12:09 AM
I've pushed a branch that should resolve #1398 and probably this one as well. The DescendantSet in my branch actually implements Set semantics. It'd be cool if someone could verify this?
-
Dan Kubb (dkubb) January 13th, 2011 @ 09:31 PM
- State changed from accepted to resolved
(from [2ffa59f0963c3a33be72ae2796f0d5d286c7d863]) Implement true set semantics for DescendantSet
Backing the DescendantSet with a SubjectSet makes
sure that when new a new constant with the same
name gets added (as is the case after code reloads
in dm-rails), the old constant with the same name
gets updated instead of the new one being appended.To make this work, a change to the way we construct
anonymous join models was needed. Previously, we
were first creating a new model class using
Model.new, and then we assigned that class to the
desired constant name. The problem with this is
that the anonymous model got added to the
DescendantSet at a time where it's desired name
hasn't yet been set. This left us with an entry in
the DescendantSet that wasn't identified by the
correct name.This patch changes the method signature of the
semipublic DataMapper::Model.new method:module DataMapper
# OLD: # The storage_name parameter has been # deprecated since Jan 2, 2009 # see: http://is.gd/e0q1RU Model.new(storage_name = nil, &block) # NEW: Model.new(name = nil, namespace = nil, &block)
end
The new signature expects "name" to be a String
and "namespace" to be a constant that will hold
the newly created model.[#1453 state:resolved] https://github.com/datamapper/dm-core/commit/2ffa59f0963c3a33be72ae...
-
Martin Gamsjaeger (snusnu) January 13th, 2011 @ 09:33 PM
- Milestone set to 1.1
- Milestone order changed from 196311 to 0
-
Martin Gamsjaeger (snusnu) January 13th, 2011 @ 09:33 PM
- Assigned user changed from Xavier Shay to Martin Gamsjaeger (snusnu)
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Tags
Referenced by
-
1453 Each request in development slows down subsequent responses [#1453 state:resolved] https://github.com/datamapper/dm-...