@@ -6,8 +6,8 @@ layout: docs.hbs
66# Easy profiling for Node.js Applications
77
88There are many third party tools available for profiling Node.js applications
9- but, in many cases, the easiest option is to use the Node.js built in profiler.
10- The built in profiler uses the [ profiler inside V8] [ ] which samples the stack at
9+ but, in many cases, the easiest option is to use the Node.js built- in profiler.
10+ The built- in profiler uses the [ profiler inside V8] [ ] which samples the stack at
1111regular intervals during program execution. It records the results of these
1212samples, along with important optimization events such as jit compiles, as a
1313series of ticks:
@@ -80,7 +80,7 @@ should not be trying to design your own cryptographic authentication mechanisms
8080in general. It is much better to use existing, proven authentication solutions.*
8181
8282Now assume that we've deployed our application and users are complaining about
83- high latency on requests. We can easily run the app with the built in profiler:
83+ high latency on requests. We can easily run the app with the built- in profiler:
8484
8585```
8686NODE_ENV=production node --prof app.js
@@ -124,7 +124,7 @@ Percentage of the requests served within a certain time (ms)
124124
125125From this output, we see that we're only managing to serve about 5 requests per
126126second and that the average request takes just under 4 seconds round trip. In a
127- real world example, we could be doing lots of work in many functions on behalf
127+ real- world example, we could be doing lots of work in many functions on behalf
128128of a user request but even in our simple example, time could be lost compiling
129129regular expressions, generating random salts, generating unique hashes from user
130130passwords, or inside the Express framework itself.
@@ -207,7 +207,7 @@ accounts not only for the 51.8% from above but also for all CPU time in the top
2072073 most sampled functions since the calls to ` _sha1_block_data_order ` and
208208` _malloc_zone_malloc ` were made on behalf of the pbkdf2 function.
209209
210- At this point, it is very clear that the password based hash generation should
210+ At this point, it is very clear that the password- based hash generation should
211211be the target of our optimization. Thankfully, you've fully internalized the
212212[ benefits of asynchronous programming] [ ] and you realize that the work to
213213generate a hash from the user's password is being done in a synchronous way and
0 commit comments