Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Performance testing crash course - Dustin Whittle

703 Aufrufe

Veröffentlicht am

The performance of your application affects your business more than you might think. Top engineering organizations think of performance not as a nice-to-have, but as a crucial feature of their product. Those organizations understand that performance has a direct impact on user experience and, ultimately, their bottom line. Unfortunately, most engineering teams do not regularly test the performance and scalability of their infrastructure. Dustin Whittle shares the latest performance testing tools and insights into why your team should add performance testing to the development process. Learn how to evaluate performance and scalability on the server-side and the client-side with tools like Siege, Bees with Machine Guns, Google PageSpeed, WBench, and more. Take back an understanding of how to automate performance and load testing and evaluate the impact it has on performance and your business.

Veröffentlicht in: Daten & Analysen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Performance testing crash course - Dustin Whittle

  1. 1. Performance Tes-ng Crash Course Dus$n Whi*le
  2. 2. Dus-n Whi5le • dus-nwhi5le.com • @dus-nwhi5le • San Francisco, California, USA • Technologist, Traveler, Pilot, Skier, Diver, Sailor, Golfer
  3. 3. Why does performance ma5er?
  4. 4. Performance directly impacts the bo5om line
  5. 5. How fast is fast enough? § Performance is key to a great user experience - Under 100ms is perceived as reac$ng instantaneously - A 100ms to 300ms delay is percep$ble - 1 second is about the limit for the user's flow of thought to stay uninterrupted - Users expect a site to load in 2 seconds - AMer 3 seconds, 40% will abandon your site. - 10 seconds is about the limit for keeping the user's a*en$on § Modern applica-ons spend more -me in the browser than on the server-side
  6. 6. Treat performance as a feature!
  7. 7. Tools of the trade for performance tes-ng
  8. 8. Understand your baseline performance
  9. 9. Sta-c vs Hello World vs Applica-ons
  10. 10. Apache Bench
  11. 11. ab -c 1 -t 10 -k http://acmedemoapp.com/
  12. 12. Benchmarking acmedemoapp.com (be patient) Finished 187 requests Server Software: Apache-Coyote/1.1 Server Hostname: acmedemoapp.com Server Port: 80 Document Path: / Document Length: 5217 bytes Concurrency Level: 1 Time taken for tests: 10.039 seconds Complete requests: 187 Failed requests: 0 Keep-Alive requests: 187 Total transferred: 1021768 bytes HTML transferred: 975579 bytes Requests per second: 18.63 [#/sec] (mean) Time per request: 53.687 [ms] (mean)
  13. 13. ab -c 10 -t 10 -k http://acmedemoapp.com/
  14. 14. Benchmarking acmedemoapp.com (be patient) Finished 659 requests Server Software: Apache-Coyote/1.1 Server Hostname: acmedemoapp.com Server Port: 80 Document Path: / Document Length: 5217 bytes Concurrency Level: 10 Time taken for tests: 10.015 seconds Complete requests: 659 Failed requests: 0 Keep-Alive requests: 659 Total transferred: 3600776 bytes HTML transferred: 3438003 bytes Requests per second: 65.80 [#/sec] (mean) Time per request: 151.970 [ms] (mean) Time per request: 15.197 [ms] (mean, across all
  15. 15. Siege
  16. 16. siege -c 10 -b -t 10S http://acmedemoapp.com/
  17. 17. ** SIEGE 3.0.6 ** Preparing 10 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 623 hits Availability: 100.00 % Elapsed time: 9.57 secs Data transferred: 3.10 MB Response time: 0.15 secs Transaction rate: 65.10 trans/sec Throughput: 0.32 MB/sec Concurrency: 9.91 Successful transactions: 623 Failed transactions: 0 Longest transaction: 0.30 Shortest transaction: 0.10
  18. 18. What about when you need more than one machine?
  19. 19. Bees with Machine Guns
  20. 20. A utility for arming (creating) many bees (micro EC2 instances) to attack (load test) targets (web applications)
  21. 21. pip install beeswithmachineguns
  22. 22. # ~/.boto [Credentials] aws_access_key_id=xxx aws_secret_access_key=xxx [Boto] ec2_region_name = us-west-2 ec2_region_endpoint = ec2.us-west-2.amazonaws.com
  23. 23. bees up -s 2 -g default -z us-west-2b -i ami-bc05898c -k appdynamics- dustinwhittle-aws-us-west-2 -l ec2-user
  24. 24. Connecting to the hive. Attempting to call up 2 bees. Waiting for bees to load their machine guns... . . . . Bee i-3828400c is ready for the attack. Bee i-3928400d is ready for the attack. The swarm has assembled 2 bees.
  25. 25. bees attack -n 1000 -c 50 -u http://acmedemoapp.com/
  26. 26. Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 500 rounds, 25 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. … Offensive complete. Complete requests: 1000 Requests per second: 306.540000 [#/sec] (mean) Time per request: 163.112000 [ms] (mean) 50% response time: 151.000000 [ms] (mean) 90% response time: 192.000000 [ms] (mean) Mission Assessment: Target crushed bee offensive. The swarm is awaiting new orders.
  27. 27. bees attack -n 100000 -c 1000 -u http://acmedemoapp.com/
  28. 28. Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 50000 rounds, 500 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. … Offensive complete. Complete requests: 100000 Requests per second: 502.420000 [#/sec] (mean) Time per request: 360.114000 [ms] (mean) 50% response time: 451.000000 [ms] (mean) 90% response time: 402.000000 [ms] (mean) Mission Assessment: Target crushed bee offensive. The swarm is awaiting new orders.
  29. 29. Read 2 bees from the roster. Connecting to the hive. Assembling bees. Each of 2 bees will fire 50000 rounds, 500 at a time. Stinging URL so it will be cached for the attack. Organizing the swarm. Bee 0 is joining the swarm. Bee 1 is joining the swarm. Bee 0 is firing his machine gun. Bang bang! Bee 0 lost sight of the target (connection timed out). Bee 1 lost sight of the target (connection timed out). Offensive complete. Target timed out without fully responding to 2 bees. No bees completed the mission. Apparently your bees are peace-loving hippies. The swarm is awaiting new orders.
  30. 30. bees down
  31. 31. Read 2 bees from the roster. Connecting to the hive. Calling off the swarm. Stood down 2 bees.
  32. 32. locust.io https://github.com/locustio/locust
  33. 33. pip install locustio
  34. 34. There are many tools… •Gatling.io •Wrk •Vegeta •Tsung •…
  35. 35. In modern web applications more latency comes from the client-side than the server-side.
  36. 36. npm install psi
  37. 37. WBench
  38. 38. gem install wbench
  39. 39. wbench h5p://dus-nwhi5le.com/
  40. 40. Automate client-side performance tes-ng with Grunt/Gulp
  41. 41. How many people understand exactly how fast their site runs in produc-on?
  42. 42. Instrument everything = code, databases, caches, queues, third party services, and infrastructure.
  43. 43. Track performance in development and produc-on
  44. 44. webpagetest.org
  45. 45. SiteSpeed.io
  46. 46. Load tes-ng services from the cloud
  47. 47. Test for failures • NetFlix Simian Army + Chaos Monkey
 • What happens if you lose a caching layer? • What happens if dependencies slow down?
  48. 48. Best Prac$ces • Treat performance as a feature • Capacity plan and load test the server-side • Op-mize and performance test the client-side • Understand your star-ng point • Instrument everything • Monitor performance in development and produc-on • Measure the difference of every change • Automate performance tes-ng in your build and deployment process • Understand how failures impact performance
  49. 49. The protocols are evolving • The limita$ons of HTTP/1.X forced us to develop various applica$on workarounds (sharding, concatena$on, spri$ng, inlining, etc.) to op$mize performance. However, in the process we’ve also introduced numerous regressions: poor caching, unnecessary downloads, delayed execu$on, and more. • HTTP/2 eliminates the need for these hacks and allows us to both simplify our applica$ons and deliver improved performance. • You should unshard, unconcat, and unsprite your assets • You should switch from inlining to server push • Read Ilya Grigorik awesome book on browser performance - h*p://hpbn.co/ h*p2
  50. 50. Integrate automated performance tes-ng into con-nuous integra-on for server-side and client-side
  51. 51. Understand the performance implica-ons of every deployment and package upgrade
  52. 52. Monitor end user experience from end to end in produc-on
  53. 53. Ques-ons?
  54. 54. Find these slides on SpeakerDeck h5ps://speakerdeck.com/dus-nwhi5le
  55. 55. http://www.appdynamics.com/

×