We were noticing slow response times in some of our ENV and ran a profiling tool (ruby-prof) to determine where the time was being spent.
When we profiled SomeObject.all.with_associations(:content_type) we noticed a lot of exceptions coming from inside RelWrapping#wrapper: (Note the ~250 exceptions and that most of the time is spent inside of DidYouMean )
From here we looked at #wrapperline 27 We thought based on this rails issue that maybe the end of the line should actually be rel_type.to_s.underscore.camelize since "camelize expects the string to be lowercase and with _".
Also, looking at Neo4j::ActiveRel::Types::WRAPPED_CLASSES showed us :HAS_CONTENT_TYPE=>"HASContentType" ...where we think it should actually be HasContentType.
Once we made the above underscore change and reran the profiler we got: (Note only ~60 exceptions)
We suspected it might be a load order issue because our production env is slow...but so far development has been consistently fast
... since we didn't have a HasContentType ActiveRel model defined in our application and as a result didn't have a model for it to preload?
So next, we created HasContentType as an ActiveRel model in our application. This time, when we tried profiling in the rails console, the HasContentType model loaded, there were no exceptions, and there was a much better performance time (took about 1/4 as long):
Things we still don't understand...
Not all of our associations that don't have ActiveRel model definitions are preforming slowly / getting DidYouMean exceptions.
How some key/values are being added to Neo4j::ActiveRel::Types::WRAPPED_CLASSES with incorrect casing
Why Production consistently has the incorrect WRAPPED_CLASSES and our development environments have the correctly cased WRAPPED_CLASSES. Is the load order different somehow? (we ran prod and dev against the exact same DB to be sure it wasn't just a difference in datasets)
What we are doing...
Currently, we are heading down the route of adding ActiveRel classes for all of our association types... but if anyone can point us in the right direction or has ideas of something else to try, we'd love to contribute back to this repo. But since adding underscore didn't fix all of the exceptions, we don't currently feel like we have a good enough handle on what is causing the issue.
We were noticing slow response times in some of our ENV and ran a profiling tool (
ruby-prof
) to determine where the time was being spent.When we profiled
SomeObject.all.with_associations(:content_type)
we noticed a lot of exceptions coming from insideRelWrapping#wrapper
: (Note the ~250 exceptions and that most of the time is spent inside ofDidYouMean
)From here we looked at
#wrapper
line 27 We thought based on this rails issue that maybe the end of the line should actually berel_type.to_s.underscore.camelize
since "camelize expects the string to be lowercase and with _". Also, looking atNeo4j::ActiveRel::Types::WRAPPED_CLASSES
showed us:HAS_CONTENT_TYPE=>"HASContentType"
...where we think it should actually beHasContentType
.Once we made the above
underscore
change and reran the profiler we got: (Note only ~60 exceptions)We suspected it might be a load order issue because our production env is slow...but so far development has been consistently fast
... since we didn't have a
HasContentType
ActiveRel model defined in our application and as a result didn't have a model for it to preload?So next, we created
HasContentType
as an ActiveRel model in our application. This time, when we tried profiling in the rails console, theHasContentType
model loaded, there were no exceptions, and there was a much better performance time (took about 1/4 as long):Things we still don't understand...
DidYouMean
exceptions.Neo4j::ActiveRel::Types::WRAPPED_CLASSES
with incorrect casingWRAPPED_CLASSES
and our development environments have the correctly casedWRAPPED_CLASSES
. Is the load order different somehow? (we ran prod and dev against the exact same DB to be sure it wasn't just a difference in datasets)What we are doing...
Currently, we are heading down the route of adding ActiveRel classes for all of our association types... but if anyone can point us in the right direction or has ideas of something else to try, we'd love to contribute back to this repo. But since adding
underscore
didn't fix all of the exceptions, we don't currently feel like we have a good enough handle on what is causing the issue.Runtime information:
Neo4j database version:
neo4j
gem version:9.3
neo4j-core
gem version:7.2.2