Slide 1

Slide 1 text

stormforger.com - stormforger.com - stormforger.com stormforger.com - stormforger.com - stormforger.com

Slide 2

Slide 2 text

stormforger.com - stormforger.com - stormforger.com stormforger.com - stormforger.com - stormforger.com

Slide 3

Slide 3 text

@tisba First, some Questions…

Slide 4

Slide 4 text

@tisba Who does not know what Serverless means?

Slide 5

Slide 5 text

@tisba Who is doing
 Serverless in production?

Slide 6

Slide 6 text

@tisba Who is doing
 performance testing?

Slide 7

Slide 7 text

@tisba ! AWS User Group CGN • Sebastian Cohnen (@tisba) • 9+ years consulting & development • focus on performance and architecture • founder & CTO StormForger

Slide 8

Slide 8 text

StormForger Start Perf Testing Now! StormForger.com • Performance Testing SaaS for DevOps Teams • Fully managed, focused on integration and continuous performance testing

Slide 9

Slide 9 text

Performance Testing
 AWS Serverless Sebastian Cohnen, @tisba StormForger.com *SCNR* *SCNR*

Slide 10

Slide 10 text

@tisba Why perf testing Serverless?

Slide 11

Slide 11 text

@tisba Serverless? * … a gross simplification Application State / Data Runtime OS Serverless Application State / Data Runtime OS Containers Application State / Data Runtime OS … VM Networking Networking Networking … … … Application State / Data Runtime OS Bare Metal Networking Hardware … … … … … …

Slide 12

Slide 12 text

@tisba Serverless • …might have an impact on how you build your systems • …systems will still be quite complex and distributed • …might be used for (µ-)Services

Slide 13

Slide 13 text

@tisba

Slide 14

Slide 14 text

@tisba

Slide 15

Slide 15 text

@tisba Performance Testing Serverless! • Learning about system behaviour • Correct sizing & cost optimisations
 • Stateless • Issues with observability

Slide 16

Slide 16 text

@tisba Strategies • Get started! Pragmatism over Perfection • Divide and Conquer • Two perspectives: “End-to-End” & “per Unit” • Move downward in the stack

Slide 17

Slide 17 text

@tisba End-to-End • Scenarios modelled around actual usage • Perspective is a perimeter view • Can generate quite some noise when problems occur • Usually answers business questions best Unit • Test components or units in isolation • Very useful for teams to debug & troubleshoot performance issues • Good for checking technical SLO • Very hard to model in a way that is representative

Slide 18

Slide 18 text

@tisba Moving down the Stack

Slide 19

Slide 19 text

@tisba CloudFront API GW Lambda Test Traffic Moving down the Stack

Slide 20

Slide 20 text

@tisba CloudFront API GW Lambda Test Traffic Moving down the Stack

Slide 21

Slide 21 text

@tisba API GW Lambda CloudFront API GW Lambda Test Traffic API GW Lambda DynamoDB Moving down the Stack

Slide 22

Slide 22 text

@tisba API GW Lambda API GW Lambda Test Traffic API GW Lambda CloudFront Moving down the Stack DynamoDB ElastiCache

Slide 23

Slide 23 text

@tisba Observability

Slide 24

Slide 24 text

@tisba Can you quickly figure out the reason for
 an increased latency or error rate for a specific endpoint?

Slide 25

Slide 25 text

@tisba

Slide 26

Slide 26 text

@tisba Observability • Logs • Metrics • Tracing
 • Check out theburningmink.com, e.g.
 https://theburningmonk.com/2018/04/ serverless-observability-what-can-you- use-out-of-the-box/

Slide 27

Slide 27 text

@tisba Performance Testing:
 Exercise to check for Observability

Slide 28

Slide 28 text

@tisba Common Pitfalls

Slide 29

Slide 29 text

@tisba HTTP Keep-Alive • Using network connections for multiple requests
 • otherwise extremely wasteful in terms of resources • Keep-Alive significantly decreases latency and resource utilisation connection: ~54%

Slide 30

Slide 30 text

@tisba Who is using Node.js?

Slide 31

Slide 31 text

@tisba HTTP Keep-Alive • Using network connections for multiple requests
 • otherwise extremely wasteful in terms of resources • Keep-Alive significantly decreases latency and resource utilisation • e.g. Node.js does not keep alive HTTP client connections by default ⚠ connection: ~54%

Slide 32

Slide 32 text

@tisba HTTP Keep-Alive • AWS Lambda are stateless • State is being externalised, often times over HTTP • Our upstream services are typically using HTTP • …and almost all AWS Services are talked to over HTTP as well!

Slide 33

Slide 33 text

@tisba Remember Observability? • Networking and OS-level operations are hard to observe! • Instrumenting Network operations is next to impossible (AFAIK) • ephemeral port exhaustion, socket statistics, … Application State / Data Runtime OS … Serverless Networking … { ?

Slide 34

Slide 34 text

@tisba Let’s Test This!

Slide 35

Slide 35 text

@tisba definition.session("keep-alive", function(session) { session.times(25, function(context) { // HTTP 1.1 with HTTP Keep-Alive is the default context.get("http://testapp.loadtest.party/", { tag: "keep-alive" }); context.waitExp(0.5); }); }); 
 definition.session("no-keep-alive", function(session) { session.times(25, function(context) { context.get("https://testapp.loadtest.party/", { tag: "no-keep-alive", // instruct client to close connection after request is done headers: { Connection: "close", }, }); context.waitExp(0.5); }); });

Slide 36

Slide 36 text

@tisba Only moments later… Only moments later…

Slide 37

Slide 37 text

@tisba bimodal distribution

Slide 38

Slide 38 text

@tisba time (ms) 0 300 600 900 1.200 median p99.9 max 1.158 242 122 262 85 29 HTTP Keep-Alive Impact* -76% -65% * Traffic generated from two instances to a single target, over 5 minutes, 25 requests per connection (keep-alive), ~200k requests in total, ~337 TCP&TLS handshakes/sec, avg test cluster CPU utilisation ~50%. -77%

Slide 39

Slide 39 text

@tisba PS: Don’t forget about other connection pools ! RDS, ElastiCache, …

Slide 40

Slide 40 text

@tisba Questions? Don’t be
 that guy! Start Perf Testing Now! StormForger.com

Slide 41

Slide 41 text

@tisba Bonus Level!

Slide 42

Slide 42 text

@tisba Private VPCs • You can use AWS Lambda that are running in your private VPCs • Keep in mind that they allocate IP addresses from the VPC they are running in • If you are running out of address space (hello IPv4), weird things will happen!

Slide 43

Slide 43 text

@tisba Cascading Failures & Timeouts • Know your timeouts for all layers • Circuit breakers, exponential back off • Ideally: Deadline & Cancellation Propagation https://landing.google.com/sre/sre-book/chapters/addressing-cascading-failures/