Designing for Concurrency &
Performance
Vikas Hazrati
Knoldus Software LLP
2
vikas hazrati
CTO and Co-Founder @ Knoldus Software
16 years
Still on the JVM though with Scala
Big data systems with ma...
3
concurrency & performance
»What?
4
5
6
performance == scalability ?
7
performance != scalability
8
9
latency == throughput
10
ways to manage concurrency
11
threads
Mapped to cpuMapped to cpu
High degree of control
To the metal – no overhead
heavyweight
scarce
heavyweight
Dim...
12
executor
Mapped to cpuconfigurable
Higher level abstraction
Maintain thread ratio
heavyweight
blocking
Error handling
E...
13
stm
Mapped to cputypesafe
transactional
Non blocking
heavyweight
contention
size
Reruns while in
contention
Side effect...
14
futures
Mapped to cputypesafe
configurable
Non blocking
heavyweight
Can close over
Mutable state
Error handling to
call...
15
concurrency is hard!
16
is performance any simpler?
17
today's systems
Scalable
Failure resistant
Quick response
React to events
18
they need to be REACTIVE!
19
20
understand the tradeoffs
Performance Scalability
Throughput Latency
Availability Consistency
21
things to remember
22
event driven
23
indeterministic need locks
threads and shared mutable state
24
locks
break encapsulation
never sure of the right amount
deadlocks
error recovery is hard
25
never block
kills scalability and
performance
wastes resources
use non blocking IO
lock free concurrency
26
go parallel
27
percentage of code in parallel
28
react to load
scalability
29
location transparency
30
go event driven
31
how to go event driven?
Shared nothing
Lightweight
Async message passing
Non-blocking
Location transparent
Mailbox
32
resilience
33
fault tolerance
Isolate
Compartmentalize
Local resolution
Avoid cascades
34
fault tolerance
Errors handled by
Supervisor
In async mode
Supervisor can kill / start /
Manage/ resume
35
responsive
36
responsive
throughput
latency
37
38
39
batch em
40
41
42
43
44
45
how?
46
47
48
49
actor
Embodies
Processing
Storage
Communication
50
actors
Mapped to cpuencapsulation
configurable
Fault tolerant
heavyweight
Lifecycle management
untyped
Easy to violate
...
51
distributable by design
Location Transparent
Scale up and down
Fault tolerant
Adaptive load balancing
Extremely loosely...
52
fault tolerant
53
54
55
56
57
58
59
60
Thanks!
vikas@knoldus.com
@vhazrati
Www.knoldus.com
@knolspeak
Upcoming SlideShare
Loading in …5
×

Designing for concurrency and performance

571 views

Published on

Knoldus speaking at the IndicThreads 2013 conference in New Delhi on how Scala and Akka can help in building reactive applications.

References
1) Concurrency talk to Klang and Kuhn at ScalaDays 2013
2) Reactive applications talk by Boner at ScalaDays 2013
3) Reactive Manifesto
4) Blog.knoldus.com

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
571
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Designing for concurrency and performance

  1. 1. Designing for Concurrency & Performance Vikas Hazrati Knoldus Software LLP
  2. 2. 2 vikas hazrati CTO and Co-Founder @ Knoldus Software 16 years Still on the JVM though with Scala Big data systems with massive computations
  3. 3. 3 concurrency & performance »What?
  4. 4. 4
  5. 5. 5
  6. 6. 6 performance == scalability ?
  7. 7. 7 performance != scalability
  8. 8. 8
  9. 9. 9 latency == throughput
  10. 10. 10 ways to manage concurrency
  11. 11. 11 threads Mapped to cpuMapped to cpu High degree of control To the metal – no overhead heavyweight scarce heavyweight Diminishing returns Low level Failure recovery hard Threadsafe? locks? Ordering of locks?
  12. 12. 12 executor Mapped to cpuconfigurable Higher level abstraction Maintain thread ratio heavyweight blocking Error handling Easy closure over state Failure recovery hard Call back hell? Low reusability? Sync or async Less jmm headache Higher level abstraction
  13. 13. 13 stm Mapped to cputypesafe transactional Non blocking heavyweight contention size Reruns while in contention Side effect in retries? Failure handling? Unpredictable performance composable Debugging is hard
  14. 14. 14 futures Mapped to cputypesafe configurable Non blocking heavyweight Can close over Mutable state Error handling to callee Ordering of callbacks Callback hell Recover with lock composable freely sharable
  15. 15. 15 concurrency is hard!
  16. 16. 16 is performance any simpler?
  17. 17. 17 today's systems Scalable Failure resistant Quick response React to events
  18. 18. 18 they need to be REACTIVE!
  19. 19. 19
  20. 20. 20 understand the tradeoffs Performance Scalability Throughput Latency Availability Consistency
  21. 21. 21 things to remember
  22. 22. 22 event driven
  23. 23. 23 indeterministic need locks threads and shared mutable state
  24. 24. 24 locks break encapsulation never sure of the right amount deadlocks error recovery is hard
  25. 25. 25 never block kills scalability and performance wastes resources use non blocking IO lock free concurrency
  26. 26. 26 go parallel
  27. 27. 27 percentage of code in parallel
  28. 28. 28 react to load scalability
  29. 29. 29 location transparency
  30. 30. 30 go event driven
  31. 31. 31 how to go event driven? Shared nothing Lightweight Async message passing Non-blocking Location transparent Mailbox
  32. 32. 32 resilience
  33. 33. 33 fault tolerance Isolate Compartmentalize Local resolution Avoid cascades
  34. 34. 34 fault tolerance Errors handled by Supervisor In async mode Supervisor can kill / start / Manage/ resume
  35. 35. 35 responsive
  36. 36. 36 responsive throughput latency
  37. 37. 37
  38. 38. 38
  39. 39. 39 batch em
  40. 40. 40
  41. 41. 41
  42. 42. 42
  43. 43. 43
  44. 44. 44
  45. 45. 45 how?
  46. 46. 46
  47. 47. 47
  48. 48. 48
  49. 49. 49 actor Embodies Processing Storage Communication
  50. 50. 50 actors Mapped to cpuencapsulation configurable Fault tolerant heavyweight Lifecycle management untyped Easy to violate encapsulation Location trasparency Models real world
  51. 51. 51 distributable by design Location Transparent Scale up and down Fault tolerant Adaptive load balancing Extremely loosely coupled
  52. 52. 52 fault tolerant
  53. 53. 53
  54. 54. 54
  55. 55. 55
  56. 56. 56
  57. 57. 57
  58. 58. 58
  59. 59. 59
  60. 60. 60 Thanks! vikas@knoldus.com @vhazrati Www.knoldus.com @knolspeak

×