Architecture for Speed
Chris B. Behrens
@chrisbbehrens
Up Next:
A Shift in Focus
Monolithic Architecture vs. Microservices
Why does it take so long to
Services should be separable
authenticate on Fridays?
Do what you need to
and nothing more.
Do what you need to, when
you need to, and nothing
more.
Time-shifting
Async
This was a problem general enough that Microsoft
created a framework to solve it
Async creates a call and return delegate under the
covers
The sum of operations is probably longer
But the user experience is better
A website with a lot of operations to execute on startup
Approach 1: Load everything on the server and make the
user wait
q+x+y+z
q+ max(x,y,z)
Fan Out, Fan In
LoadProfile()
Y
Page
openDbConnection() closeDbConnection()
overhead
X c
q
LoadOrders()
Z
x + max(y, z) + c + q
Using Queuing to Time-shift
“We’ll do it later”
A shopping cart app in the Paleozoic era
of the nineties
The partner recommended expensive
bandwidth that wouldn’t really
solve the problem
But how often does validation fail?
Not very often
We executed that validation later on and
circled back with the user if it failed
Message Queuing
Your application creates a
A message queue server
message in the queue
Later on, the queue And the user has no idea it
is processed didn’t’ happen instantly
The Role of Caching
Early Internet Broadcasts
Software to Live, recorded, My part was the We forward-
manage and slide routing and cached the
webcasts content traffic manager content to the
network
A Smaller Scale Example
Other slower
We forward-cached We traded memory
methods use less
the file ACL for speed
memory
We hold the ACL in Whether it’s being
memory used or not
Do what you need to, when
you need to, and nothing
more
Trading Memory for Speed
Check out Redis cache Set expiration on data calls
You probably don’t need it as
Consider your data volatility
often as you think
Planetary Scale Architecture
Working with Multiple Databases
9772 km
Consistent within .01 seconds
Consistent within .03 seconds
in ideal circumstances
My Point
We need to decide what our
All consistency is eventual
consistency needs to be
A strong separation of read-only
This is useful in deployment
and consistency
Loose Dependencies
Dependencies should be Here today, there tomorrow
low-commitment
Configuration as a Service
Don’t hard-code Config should come With a universal copy
config, not even in from the environment of the code
config files
Scaling Up vs. Scaling Out
Scaling out Pure code needs
Throw hardware at
requires less (no?)
it – scale up
orchestration orchestration
Map Reduce
A superwide Part of the general
orchestration Map, then Reduce split-apply-combine
pattern pattern
At first, the work is But over time, you Map Reduce can be
not readily make the work accomplished with
decomposable decomposable advanced LINQ
A Map Reduce Example
Courtesy of StackOverflow
Course Wrap-up
How to “Well, Actually…”
1. A link to your Github code
2. Post your benchmarks
3. Describe trade-offs to readability,
maintainability and other relevant -ilities
https://github.com/FeynmanFan
/csharpperformanceplaybook
THANK YOU VERY MUCH
FOR WATCHING!!!
