diff options
author | FiveFilters.org <[email protected]> | 2021-08-25 13:39:55 +0200 |
---|---|---|
committer | FiveFilters.org <[email protected]> | 2021-08-25 13:39:55 +0200 |
commit | 4c42348ab2e316af537dc9ba85005ee8a9baebf5 (patch) | |
tree | 48ca7b816d2466a6b35dce611cde6b98ac3a933e /test/test-pages/lazy-image-1/expected.html | |
parent | c4a6cf576b6e9870d64d833816f93c45dd36d090 (diff) |
Fix headers being removed
https://github.com/mozilla/readability/commit/11093f011f57fa528a00a78d70b8d9df32c7a32d
Diffstat (limited to 'test/test-pages/lazy-image-1/expected.html')
-rw-r--r-- | test/test-pages/lazy-image-1/expected.html | 40 |
1 files changed, 30 insertions, 10 deletions
diff --git a/test/test-pages/lazy-image-1/expected.html b/test/test-pages/lazy-image-1/expected.html index 2092395..1c98070 100644 --- a/test/test-pages/lazy-image-1/expected.html +++ b/test/test-pages/lazy-image-1/expected.html @@ -4,14 +4,18 @@ </p> </div> - + <h2 id="0231"> + Why CPU monitoring is important? + </h2> <p id="d2c1"> I work at <a href="http://voodoo.io/" target="_blank" rel="noopener nofollow">Voodoo</a>, a French company that creates mobile video games. We have a lot of challenges with performance, availability, and scalability because of the insane amount of traffic our infrastructure supports (billions of events/requests per day …… no joke!). In this setting, every metric is important and gives us a lot of information about the state of our system. </p> <p id="0e89"> When working with Node.js one of the most critical resources to monitor is the CPU. Most of the time, when working on a low traffic API or project we don’t realize how many simple lines of code can have a huge impact on CPU. On the other hand, when traffic increases, a simple mistake can cost dearly. </p> - + <h2 id="292e"> + Resources + </h2> <p id="1efa"> What kind of resources does your application need? In most cases, we focus on memory and CPU. Good monitoring of these two elements is mandatory for an application running on production. </p> @@ -53,7 +57,9 @@ <p id="0728"> And what next? We don’t have data about the state of the instance when the CPU usage has increased. So we can’t determine why we had this peak, at least not without an important time of debugging, comparing log, etc. This is exactly why you need to use CPU profiling. </p> - + <h2 id="8d00"> + CPU profiling: what’s the difference with CPU monitoring? + </h2> <blockquote> <p> “Most commonly, profiling information serves to aid program optimization. Profiling is achieved by instrumenting either the program source code or its binary executable form using a tool called a profiler” @@ -65,7 +71,9 @@ <p id="91c5"> It will help you to track the exact file, line, and function which takes the most time to execute. </p> - + <h2 id="088b"> + What about existing solutions? + </h2> <h2 id="dd40"> Add arguments to Node.js </h2> @@ -146,7 +154,9 @@ Unfortunately, CPU issues have a worrying tendency to occur on production, and when you are not in front of your screen. </p> </blockquote> - + <h2 id="13ef"> + Inspector + </h2> <p id="294e"> “Inspector” refers to an API thanks to which you can debug your application. By debugging we mean to be able to connect directly to the core of Node.js to collect real-time data about the process. </p> @@ -181,7 +191,9 @@ <figure> </figure> - + <h2 id="848b"> + And now, CPU profiling on-demand! + </h2> <p id="6933"> We have an API that we want to test with autocannon tool. At this step, our project is able to serve around 200 requests in 20 seconds. There is probably a mistake somewhere in the code which slows down our application. </p> @@ -264,7 +276,9 @@ </p> </div> </figure> - + <h2 id="98b9"> + More than just CPU profiling + </h2> <p id="e1ad"> With the inspector module, you can do much more than just CPU profiling, here is a non-exhaustive list: </p> @@ -276,7 +290,9 @@ <li id="b896">use the debugger in real-time </li> </ul> - + <h2 id="06d2"> + Warnings + </h2> <p id="731b"> Every tool, even the most powerful, comes with its own disadvantages. If you enable the profiler and/or the debugger on your production you have to keep an eye on two things: </p> @@ -295,7 +311,9 @@ <p id="7999"> Using the inspector in Node.js it’s like opening the door of the core of your application. You should be very careful about who can use features like CPU profiling and/or the debugger. Never make the inspector “public” as being able to launch a feature from an unsafe route (not protected with an authentification mechanism). Even the collected data can be seen as critical, never send it to a system you do not trust. </p> - + <h2 id="5618"> + Conclusion + </h2> <p id="ae1a"> CPU profiling is really a must-have tool for every developer. And now, with some precautions, we can run it on production thanks to the amazing work done by the V8 and Node.js team. </p> @@ -305,7 +323,9 @@ <p id="0aba"> I will write another article about using CPU profiling and the inspector on production on a high traffic project. </p> - + <h2 id="3c5b"> + Sources & links + </h2> <ul class> <li id="d86d"> <a href="https://nodejs.org/api/inspector.html" target="_blank" rel="noopener nofollow">https://nodejs.org/api/inspector.html</a> |