4 Node.js Gotchas: What your ops team needs to know
•Als PPTX, PDF herunterladen•
0 gefällt mir•260 views
To register for this webinar replay, click here: https://info.dynatrace.com/apm_wc_nodejs_na_registration.html There is no doubt that Node.js is one of the fastest growing platforms today. It can be found at start-ups and enterprises throughout all industries from high-tech to healthcare. A lot of people have written about the reasons for its popularity and why it has made sense in “digital transformation” efforts. But when you implement Node.js, do you have to replace your mainframes and legacy software with a shiny new Node.js-based microservice architecture? This 30-minute webinar walks in the shoes of those who oversee the whole digital value chain: Operation and performance teams. We will cover: Node.js implementation requirements (Hint: you might not have to gut your whole system) What challenges operations and performance teams face when they begin to implement Node.js The big four gotchas that can make using Node.js difficult for an operations team Gain the know-how to support your development and ops teams in implementing Node.js.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 4 Node.js Gotchas: What your ops team needs to know
Ähnlich wie 4 Node.js Gotchas: What your ops team needs to know (20)
Mehr von Dynatrace
Mehr von Dynatrace (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
4 Node.js Gotchas: What your ops team needs to know
- 1. 4 Node.js Gotchas: What your ops team needs to know khandaniel @dkhan Daniel Khan Technical Product Manager
- 5. Node.js is what the Company Outlaws use to finally introduce change
- 10. Node.js is what the Company Hipsters threw in just to break everything
- 12. @dkhan Don’t try to be funny! What is Node.js really?
- 15. Node.js is a C++ program controlled by V8 JavaScript
- 20. 1 - Memory Problems
- 22. process.memoryUsage() { rss: 4935680, heapTotal: 1826816, heapUsed: 650472 }
- 32. How to build a Memory Leak
- 36. http://bit.ly/1PvijIy var snap = profiler.takeSnapshot(); snap.serialize(); v8-profiler
- 37. D e l t a
- 38. 2 - CPU Problems
- 39. The Node.js Event Loop!
- 42. Timers IO Callbacks IO Polling Set Immediate Close Threads
- 43. 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 0 10,000,000 20,000,000 30,000,000 40,000,000 50,000,000 60,000,000 70,000,000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101103105107109 NODEJS_UV_LOOP_COUNT NODEJS_UV_LOOP_TOTAL_TIME 0 20,000 40,000 60,000 80,000 100,000 120,000 140,000 160,000 0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101103105107109 NODEJS_UV_LOOP_LATENCY NODEJS_UV_WORK_PROCESSED_LATENCY
- 45. 0.00 20,000,000.00 40,000,000.00 60,000,000.00 80,000,000.00 100,000,000.00 120,000,000.00 0.00 100.00 200.00 300.00 400.00 500.00 600.00 700.00 800.00 NODEJS_UV_LOOP_COUNT NODEJS_UV_LOOP_TOTAL_TIME 0.00 200,000,000.00 400,000,000.00 600,000,000.00 800,000,000.00 1,000,000,000.00 1,200,000,000.00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 0.00 500,000.00 1,000,000.00 1,500,000.00 2,000,000.00 2,500,000.00 3,000,000.00 3,500,000.00 4,000,000.00 NODEJS_UV_WORK_PROCESSED_LATENCY NODEJS_UV_LOOP_LATENCY Busy Processing Callback
- 49. get(‘/routeA’, function(){}) get(‘/routeB’, function(){}) get(‘/routeC’, function(){}) get(‘/routeD’, function(){}) get(‘/routeE’, function(){}) get(‘/routeA’, function(){}) get(‘/routeX’, function(){}) get(‘/^(route|router)/(.+)’, function(){}) HTTP GET /routeX get(‘/routeA’, function(){}) get(‘/routeX’, function(){}) O(n)
- 51. 3 - Security
- 56. 1980 20001995 2005 2010 2015 Stakeholders
- 57. 4 - Backpressure
- 59. 1000 RPS Node.js 10 RPS Ancient Legacy Backend
- 60. Timers IO Callbacks IO Polling Set Immediate Close Threads
- 61. Busy with IO Tasks 0.00 2,000.00 4,000.00 6,000.00 8,000.00 10,000.00 12,000.00 14,000.00 0.00 10,000,000.00 20,000,000.00 30,000,000.00 40,000,000.00 50,000,000.00 60,000,000.00 70,000,000.00 80,000,000.00 90,000,000.00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 NODEJS_UV_LOOP_COUNT NODEJS_UV_LOOP_TOTAL_TIME 0.00 5,000,000.00 10,000,000.00 15,000,000.00 20,000,000.00 25,000,000.00 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 0.00 100,000,000.00 200,000,000.00 300,000,000.00 400,000,000.00 500,000,000.00 600,000,000.00 700,000,000.00 800,000,000.00 900,000,000.00 1,000,000,000.00 NODEJS_UV_WORK_PROCESSED_LATENCY NODEJS_UV_LOOP_LATENCY
- 62. We need a Holistic View
- 66. Meet Application Performance Monitoring
- 67. Complete Transaction Coverage Browser / Native Mobile Java/ .NET Performance Warehouse PurePath Collector Dynatrace Server Dynatrace Client Sessions Store Exported Session Offline Session Analysis Web Server/ PHP/ Node.js C++, VB, ADK CICS Mainframe z/OS MQ/ESB Database
- 74. Thank you! Free Trial: https://www.dynatrace.com/trial/
- 75. Confidential, Dynatrace, LLC Participate in our Forum : community.dynatrace.com Like us on Facebook : facebook.com/dynatrace Follow us on LinkedIn : linkedin.com/company/dynatrace Follow us on Twitter : twitter.com/dynatrace Watch our Videos & Demos : youtube.com/dynatrace Read our Blog : https://www.dynatrace.com/blog/ Connect with us!
Hinweis der Redaktion
- Those are NOT startups. Those are big brands. This is unique.
- Server-side JavaScript Built on Google V8 Evented non-blocking IO 8.000 Lines of C/C++ Code, 2.000 Lines of JavaScript
- But I really like this definition.
- What V8 does: It translates JavaScript into machine code and runs it.
- And every running program is represented by Work done on the CPU Data Stoed im memory And here we already have our two problem classes.
- Let’s review the memory handling of Node.js It’s very common and quite like Java. RSS: Code and Stack where local variables are stored It contains the heap for where objects and closures – let’s say long living resources like objects or closures are stored
- And it’s actually very easy to query the memory usage of a given Node process.
- And this is what you get if you create a graph of a running Node application. As we already see the heapUsed graph looks funny. It somehow is very dynamic and seems to follow a pattern. Something seems to take care that memory is freed. And I have a real live example of how this works.
- The console spits this out
- And now that we have found our problem we can add this. And the weekend is saved.
- My script will look at the memory usage and it constantly grows it will create a snapshot.
- Event loop latency The latency of a timer task. The timer should be triggered in a set interval (e.g. 200ms). If it is however triggered in 250ms the latency is 50ms. Work processed latency The time that passes from adding an asynchronouswork item to the threadpool's work queue and a worker thread picking it up Event Loop Tick Frequency The number of event loop cycles during the observation interval. Event loop tick duration The time it takes the event loop to complete a loop cycle.
- the event loop is busy processing js callbacks (hence the increase in timer latency and the event loop tick frequency decrease and duration increase) user land code wird im event loop thread abgearbeitet - das heisst slow callbacks wirken sich auf die event loop zeit aus und die frequenz - darum entsteht eine latenz bei einem timer task wenn die event loop es nicht schafft den nächsten timer rechtzeitig zu feuern
- Again v8 profiler. Again a function already there in V8. This will give you this.
- So this netflix latency problem.
- the event loop is struggling with async work (e.g. fs.read) which basically means the threadpool is exhausted with long running/lot of async work (hence the increase in work item latency)
- the event loop is struggling with async work (e.g. fs.read) which basically means the threadpool is exhausted with long running/lot of async work (hence the increase in work item latency)
- Automatic Browser Injection for UEM Eliminate guesswork across the lifecycle No averages 100% all Transactions Low maintenance Private and Public cloud environments