I remember many years ago, connecting the devs to the DB via a dial-up 64kB 
modem. Worked wonders for the code that came back. Suddenly they noticed every 



Dr Greg Low

1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax
SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> | 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of David Connors
Sent: Monday, 19 September 2016 12:34 PM
To: ozDotNet <ozdotnet@ozdotnet.com>
Subject: Re: Entity Framework - the lay of the land

On Mon, 19 Sep 2016 at 10:38 Greg Keogh 
<gfke...@gmail.com<mailto:gfke...@gmail.com>> wrote:
I had an argument internally that caching was good, with the alternate side 
saying that “cache invalidation” was hard so they never use it.
I think it is "hard" but don't write it off completely. Search for "second 
level cache" and you'll see it's not that trivial to use properly. Some ORMs 
have it as an optional feature. You've got to consider what to cache, eviction 
or expiry policy, concurrency, capacity, etc. I implemented simple caching in a 
server app a long time ago, then about year later I put performance counters 
into the code and discovered that in live use the cache was usually going empty 
before it was accessed, so it was mostly ineffective. Luckily I could tweak it 
into working. So caching is great, but be careful -- GK

I'd argue caching is a good idea so long as it is not a substitute for good 
performance optimisation as you go.

As a general discipline we roll with a rule I call "10x representative data 
load" which means we take whatever we think the final system is going to run 
with for a data set, load each dev with 10x of that on their workstations, and 
make them live that dream.

The reality is that a bit of planning for optimal indexes as well as casting an 
eye over the execution plan after you write each proc isn't a lot of dev 
overhead. At least you know when what you have built rolls out it performs as 
well as it can given other constraints.


David Connors
da...@connors.com<mailto:da...@connors.com> | @davidconnors | LinkedIn | +61 
417 189 363

Reply via email to