The document discusses various principles and practices for building scalable applications, emphasizing the importance of understanding user behavior and avoiding over-engineering. It highlights the necessity of profiling code, identifying bottlenecks, and ensuring proper monitoring and analytics to predict usage patterns. Additionally, it addresses the structuring of APIs, caching strategies, and scaling storage solutions to optimize performance.

1. Sensible Scaling
Rowan Merewood

2. Sensible Scaling
“If your application doesn't scale, it's your fault not mine.”
– Rasmus Lerdorf (@rasmus)
Rowan Merewood

3. Who?

4. Who?
●
@rowan_m

5. Who?
●
@rowan_m
●
Software Engineer
& Team Lead

6. Who?
●
@rowan_m
●
Software Engineer
& Team Lead
●
@ibuildings &
@techportal

7. Why?

8. Why?
●
I've built small apps

9. Why?
●
I've built small apps
●
and pretty large ones

10. Why?
●
I've built small apps
●
and pretty large ones
●
I've seen massive
over-engineering

11. Why?
●
I've built small apps
●
and pretty large ones
●
I've seen massive
over-engineering
●
and platforms that
cannot scale

12. TDD Principles

13. TDD Principles
●
Write only enough
code to pass the test

14. TDD Principles
●
Write only enough
code to pass the test
●
Do not over-engineer

15. TDD Principles
●
Write only enough
code to pass the test
●
Do not over-engineer
●
Don't give away work
for free!

16. Build for now

17. Build for now
●
Don't be afraid to
throw code away

18. Build for now
●
Don't be afraid to
throw code away
●
XP's spikes

19. Build for now
●
Don't be afraid to
throw code away
●
XP's spikes
●
Take advantage of
current tech.
without tying
yourself to it

20. Who are your users?

21. Who are your users?
●
Lots of short visits?

22. Who are your users?
●
Lots of short visits?
●
Anonymous or
session-based?

23. Who are your users?
●
Lots of short visits?
●
Anonymous or
session-based?
●
Long, complex
interactions?

24. Who are your users?
●
Lots of short visits?
●
Anonymous or
session-based?
●
Long, complex
interactions?
●
Subscribers or
free users?

25. Monitor and Analyse
http://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/

26. Monitor and Analyse
●
Predict usage
patterns
http://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/

27. Monitor and Analyse
●
Predict usage
patterns
●
Plan for peaks and
troughs
http://community.plus.net/blog/2011/10/24/a-record-setting-manchester-derby/

28. Profiling

29. Profiling
●
You do not know
what is slow

30. Profiling
●
You do not know
what is slow
●
Ensure you measure
more than just code!

31. Profiling

32. Profiling
●
PHP - Xdebug – Derick Rethans (@derickr)
●
Kcachegrind, Webgrind, etc.

33. Profiling
●
PHP - Xdebug – Derick Rethans (@derickr)
●
Kcachegrind, Webgrind, etc.
●
PHP – XHProf

34. Profiling
●
PHP - Xdebug – Derick Rethans (@derickr)
●
Kcachegrind, Webgrind, etc.
●
PHP – XHProf
●
JavaScript – Firebug

35. Profiling
●
PHP - Xdebug – Derick Rethans (@derickr)
●
Kcachegrind, Webgrind, etc.
●
PHP – XHProf
●
JavaScript – Firebug
●
JavaScript – Venkman

36. Profiling
●
PHP - Xdebug – Derick Rethans (@derickr)
●
Kcachegrind, Webgrind, etc.
●
PHP – XHProf
●
JavaScript – Firebug
●
JavaScript – Venkman
●
General page display - YSlow

37. Profiling
●
CPU Load – top & /proc/loadavg

38. Profiling
●
CPU Load – top & /proc/loadavg
●
Disk IO – iotop

39. Profiling
●
CPU Load – top & /proc/loadavg
●
Disk IO – iotop
●
Memory – free

40. Profiling
●
CPU Load – top & /proc/loadavg
●
Disk IO – iotop
●
Memory – free
●
Network – netstat

41. Profiling
●
CPU Load – top & /proc/loadavg
●
Disk IO – iotop
●
Memory – free
●
Network – netstat
●
Monitoring – watch & time

42. Profiling under load

43. Profiling under load
●
Code bottlenecks !=
Platform bottlenecks

44. Profiling under load
●
Code bottlenecks !=
Platform bottlenecks
●
Test in production,
if possible

45. Profiling under load
●
Code bottlenecks !=
Platform bottlenecks
●
Test in production,
if possible
●
Use multiple VMs
(Vagrant can help
automate this)

46. Profiling under load
●
Code bottlenecks !=
Platform bottlenecks
●
Test in production,
if possible
●
Use multiple VMs
(Vagrant can help
automate this)
●
Use siege & ab

47. Finding bottlenecks

48. Finding bottlenecks
Right Wrong

49. Finding bottlenecks
Right Wrong
●
Database

50. Finding bottlenecks
Right Wrong
●
Database
●
Disk IO

51. Finding bottlenecks
Right Wrong
●
Database
●
Disk IO
●
External services

52. Finding bottlenecks
Right Wrong
●
Database
●
Disk IO
●
External services
●
Application work

53. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO
●
External services
●
Application work

54. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO ●
Config files
●
External services
●
Application work

55. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO ●
Config files
●
External services ●
Logging
●
Application work

56. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO ●
Config files
●
External services ●
Logging
●
Application work ●
Object instantiation

57. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO ●
Config files
●
External services ●
Logging
●
Application work ●
Object instantiation
●
Frameworks

58. Finding bottlenecks
Right Wrong
●
Database ●
Autoloaders
●
Disk IO ●
Config files
●
External services ●
Logging
●
Application work ●
Object instantiation
●
Frameworks
Ask Jo (@juokas)
about Doctrine!

59. Tell users it's slow

60. Tell users it's slow
●
User experience !=
Raw speed

61. Tell users it's slow
●
User experience !=
Raw speed
●
Keep the UI
responsive

62. Tell users it's slow
●
User experience !=
Raw speed
●
Keep the UI
responsive
●
Set expectations

63. Tell users it's slow
●
User experience !=
Raw speed
●
Keep the UI
responsive
●
Set expectations
●
Adapt to changes
(@blongden)

64. Fail gracefully

65. Fail gracefully
●
Actively choose
to time-out

66. Fail gracefully
●
Actively choose
to time-out
●
Prioritise
core/profitable
functionality

67. Fail gracefully
●
Actively choose
to time-out
●
Prioritise
core/profitable
functionality
●
Have a
BIG RED BUTTON

68. Separate functionality

69. Separate functionality
Admin Batch

70. Separate functionality
Admin Batch
●
Different users ==
diff. requirements

71. Separate functionality
Admin Batch
●
Different users ==
diff. requirements
●
No cache

72. Separate functionality
Admin Batch
●
Different users ==
diff. requirements
●
No cache
●
“Master” storage

73. Separate functionality
Admin Batch
●
Different users ==
diff. requirements
●
No cache
●
“Master” storage
●
Security

74. Separate functionality
Admin Batch
●
Different users == ●
Not time critical
diff. requirements
●
No cache
●
“Master” storage
●
Security

75. Separate functionality
Admin Batch
●
Different users == ●
Not time critical
diff. requirements ●
CPU/RAM hungry
●
No cache
●
“Master” storage
●
Security

76. Separate functionality
Admin Batch
●
Different users == ●
Not time critical
diff. requirements ●
CPU/RAM hungry
●
No cache ●
nice / ionice
●
“Master” storage
●
Security

77. Separate functionality
Admin Batch
●
Different users == ●
Not time critical
diff. requirements ●
CPU/RAM hungry
●
No cache ●
nice / ionice
●
“Master” storage ●
Network rate limiting
●
Security

78. Separate functionality
Admin Batch
●
Different users == ●
Not time critical
diff. requirements ●
CPU/RAM hungry
●
No cache ●
nice / ionice
●
“Master” storage ●
Network rate limiting
●
Security ●
Read only?

79. Configure hardware correctly

80. Configure hardware correctly
●
What is required for
1 request?

81. Configure hardware correctly
●
What is required for
1 request?
●
How many
concurrent requests?

82. Configure hardware correctly
●
What is required for
1 request?
●
How many
concurrent requests?
●
Is it a linear scale?

83. Configure hardware correctly
●
What is required for
1 request?
●
How many
concurrent requests?
●
Is it a linear scale?
●
Ask your
hosting company

84. Aim for services

85. Aim for services

86. Obey the “Law of Demeter”

87. Obey the “Law of Demeter”
●
Talk to your friends,
don't talk to
strangers

88. Obey the “Law of Demeter”
●
Talk to your friends,
don't talk to
strangers
●
Promotes
loose coupling

89. Obey the “Law of Demeter”
Good
Bad

90. Obey the “Law of Demeter”
Good
● $person->requestPayment($amount);
Bad

91. Obey the “Law of Demeter”
Good
● $person->requestPayment($amount);
Bad
●
$wallet = $person->getWallet();
●
$wallet->getMoney($amount);

92. Obey the “Law of Demeter”
Good
Bad

93. Obey the “Law of Demeter”
Good
Bad

94. Obey the “Law of Demeter”
Good
Bad

95. Create immutable objects

96. Create immutable objects
●
Objects that cannot change after creation

97. Create immutable objects
●
Objects that cannot change after creation
●
Copy On Write (COW - � ← unicode cow)

98. Create immutable objects
●
Objects that cannot change after creation
●
Copy On Write (COW - � ← unicode cow)
●
More memory-hungry, but easy to roll back

99. Create immutable objects
●
Objects that cannot change after creation
●
Copy On Write (COW - � ← unicode cow)
●
More memory-hungry, but easy to roll back
●
Value objects should be immutable

100. Create immutable objects
●
Objects that cannot change after creation
●
Copy On Write (COW - � ← unicode cow)
●
More memory-hungry, but easy to roll back
●
Value objects should be immutable
●
Think of them like a response from a service

101. Identify “single server” factors

102. Identify “single server” factors
●
File uploads / user content

103. Identify “single server” factors
●
File uploads / user content
●
IP restrictions / server access

104. Identify “single server” factors
●
File uploads / user content
●
IP restrictions / server access
●
Licensing?

105. Create services

106. Create services
Your API should be:

107. Create services
Your API should be:
●
Independent of
application state

108. Create services
Your API should be:
●
Independent of
application state
●
Loosely coupled

109. Create services
Your API should be:
●
Independent of
application state
●
Loosely coupled
●
Accepting/returning
immutable objects

110. Use caches

111. Use caches
●
REST-ful services
over HTTP let you
cache easily

112. Use caches
●
REST-ful services
over HTTP let you
cache easily
●
Internal caching is
trickier, but “out-of-
the-box” with most
frameworks

113. Use caches
●
REST-ful services
over HTTP let you
cache easily
●
Internal caching is
trickier, but “out-of-
the-box” with most
frameworks
Proxy other people's services through your own cache!

114. Use queues

115. Use queues
●
Full blown job server:
Gearman

116. Use queues
●
Full blown job server:
Gearman
●
AMQP
implementation:
RabbitMQ

117. Use queues
●
Full blown job server:
Gearman
●
AMQP
implementation:
RabbitMQ
●
Light-weight sockets:
0MQ

118. Use the right storage

119. Use the right storage

120. Use the right storage
Consistency Availability
Partitioning

121. Use the right storage
Consistency Availability
Enforced consistency Eventual consistency
(RDBMS) (NoSQL)
Partitioning

122. Scale your storage

123. Scale your storage
●
Master/slave
replication

124. Scale your storage
●
Master/slave
replication
●
Table partitioning

125. Scale your storage
●
Master/slave
replication
●
Table partitioning
●
Row partitioning

126. Scale your storage
●
Master/slave
replication
●
Table partitioning
●
Row partitioning
●
rsync

127. Scale your storage
●
Master/slave
replication
●
Table partitioning
●
Row partitioning
●
rsync
●
NFS

128. Scale your storage
●
Master/slave
replication
●
Table partitioning
●
Row partitioning
●
rsync
●
NFS
●
GlusterFS

129. Now you can use the cloud

130. Now you can use the cloud
●
Full service –
orchestra.io

131. Now you can use the cloud
●
Full service
orchestra.io
●
Infrastructure mgmt.
Scalr

132. Now you can use the cloud
●
Full service
orchestra.io
●
Infrastructure mgmt.
Scalr
●
Manually
$your_code_here

133. Now you can use the cloud
●
Full service
orchestra.io
●
Infrastructure mgmt.
Scalr
●
Manually
$your_code_here
●
Automate!
Chef & Puppet

134. Review

135. Review
●
Start with only what
you need

136. Review
●
Start with only what
you need
●
Identify the
problems

137. Review
●
Start with only what
you need
●
Identify the
problems
●
Pull the problem out
to a service

138. Review
●
Start with only what
you need
●
Identify the
problems
●
Pull the problem out
to a service
●
Distribute

139. Thank you!
● Feedback:
http://joind.in/6324
● Photos & Transformers:
Nina Merewood
● Legal?
Takara & Hasbro
● ElePHPant smuggling:
Johannes Schlüter (@phperror)
● Vintage photo nonsense:
http://pixlr.com/o-matic/