These are chat archives for DevrexLabs/OrigoDB

21st
Mar 2016
Jon Z
@jzoss
Mar 21 2016 16:03
@rofr Sorry for the super long delay.. So I see you checked in the super cool feature I wanted :)
So any tips on how to use this :)
Robert Friberg
@rofr
Mar 21 2016 16:08
@jzoss no prob, tell me if you experience any issues. I'm considering a 1.0 release with the current code base. Version 2 will be an async rewrite and a 30x performance boost on command throughput.
Jon Z
@jzoss
Mar 21 2016 16:08
Cool.. Yea.. I got distracted with more work work.. And I sorta took over a git provider for vs 2015.. So I got busy :)
Is there a release I should take to try things.. or just compile the code?
Robert Friberg
@rofr
Mar 21 2016 16:11
no release yet, so yeah compile. Or hang on for 15 minutes and I'll push a new release :)
Jon Z
@jzoss
Mar 21 2016 16:11
cool
Yea.. I went total nerd with my vs git plugin... I need to focus on something else :)
Jon Z
@jzoss
Mar 21 2016 16:29
Looking forward to the async stuff
I put a memoryCache in from of the db to speed it up a bit
Robert Friberg
@rofr
Mar 21 2016 16:32
did you notice an improvement using a cache? I wouldn't have expected anything significant
unless it's running in a remote process (in a datacenter far away) :)
or else it could be serialization slowing things down
Jon Z
@jzoss
Mar 21 2016 16:35
No.. running in proc. I did at the time, but that was a version of so back.. I was worried that it needed to be pretty fast.. Maybe way overkill.. I mean it was not hard to do at least. So.. does this keep the objects in memory.. If I remember correctly it was the serialization and deserialization hit that made it faster..
Robert Friberg
@rofr
Mar 21 2016 16:45
yes, in proc keeps entire model in memory but they are serialized/deserialized when passing to and from the engine. It's a very defensive measure which can be be disabled/configured/optimized
Jon Z
@jzoss
Mar 21 2016 16:46
Ahh.. so maybe it's overkill
Robert Friberg
@rofr
Mar 21 2016 16:47
probably
Jon Z
@jzoss
Mar 21 2016 16:48
Interesting.. Basically Iuse the memeorycache built in to sit between it
So .. on a get.. I check the memory cache ... if it is there.. I return.. if not.. I pull from the db.. and save it into the memorycache if it is there
I'm going back and adding lots of unit tests now.. so.. I happen to be unit testing that part of the code.. it's interesting..
Robert Friberg
@rofr
Mar 21 2016 16:52
caching won't hurt until the objects start getting out of sync (cache invalidation can be hard)
Jon Z
@jzoss
Mar 21 2016 16:53
Yea.. They all go through the same method.. So.. the code does not hit the db directly at all.. all through the repository
Robert Friberg
@rofr
Mar 21 2016 16:54
that's smart. only one place to change the caching behavior
are you running multithreaded? if not you can turn off ResultCloning (serialization) and ditch the cache
Jon Z
@jzoss
Mar 21 2016 16:57
Well... it's behind a webapi where it's all running async method ... but most of the repo methods are not async
Robert Friberg
@rofr
Mar 21 2016 16:58
well then there can be concurrent requests so can't assume single threaded...
Jon Z
@jzoss
Mar 21 2016 16:59
Yea... That's what I was thinking
Robert Friberg
@rofr
Mar 21 2016 17:00
Are there many objects returned query and/or are the objects large? That impacts response time/cpu as well due to serialization
Jon Z
@jzoss
Mar 21 2016 17:02
Not really. I mean.. my tests were partly artificial , so not sure if I would see much of a difference in the real world
Jon Z
@jzoss
Mar 21 2016 18:33
@rofr .. Question.. should I be able to store a dictionary in the db.. I have a model that has another class.. in that class I have a Dictionary .. not sure if it is coming back out correctly
I am using the proxy feature
Jon Z
@jzoss
Mar 21 2016 19:28
Wait never mind.. my bug