New features of Node.js V0.12: Performance optimization

The v0.12 long development cycle (which has been in the past nine months and continues, the longest ever) has given the core team and contributors ample opportunity to optimize performance. This article will introduce some of the most noteworthy.

Writable streams that support plug patterns

Now the writable stream can support the corked mode, similar to the socket options Tcp_cork and tcp_nopush you see when you execute a man TCP.

When plugged in, the data written to the stream is queued until the stream is reopened (uncorked). This allows Node.js to combine smaller writes into larger ones, thus reducing system calls and TCP round-trip.

The HTTP module has been upgraded to transparently use the plug mode when sending blocks of requests or response principals. If you often look at Strace (1) output, you will find that the Writev (2) system calls more and write (2) becomes less.

Promote TLS performance

The TLS module has been considerably reconstructed in the Node.js v0.12.

In Node.js v0.10, the TLS module is on top of the net module as a transport stream that transparently encrypts and decrypts network traffic. From an engineering standpoint, this layering is necessary, but it can lead to overhead-more memory transfers and more than absolutely necessary calls in the V8 VM-and hinders optimization.

So in Node.js v0.12, the TLS module is rewritten directly with LIBUV. Now it directly to the network traffic to pull out the encryption, without passing through the middle layer.

Although this evaluation is not scientific, the use of a blank password indicates that TLS is now generally 10% faster and uses less memory. (I would say that the reduced memory footprint may be partly due to refactoring memory management, which is another optimization of v0.12.) ）

(And, if you want to know, passwords that are not encrypted with empty passwords; they can be used to measure the overhead of schemas and protocols.) )

For end users, much of the change in the TLS module is transparent. One of the most conspicuous is that the TLS connection is now obtained from the Tls.tlssocket, not the Tls.cryptostream.

Improve Crypto performance

Back to the column page: http://www.bianceng.cnhttp://www.bianceng.cn/webkf/script/

Several encryption and decryption algorithms should now be faster, sometimes much faster. Let me introduce the background:

The node.js in the OpenSSL library is implemented using the add and decrypt. The algorithms in OpenSSL are written in C and are for manual assembly versions of various platforms and architectures.

Node.js v0.10 has already given something to the assembly version, and v0.12 has extended it to a large extent. In addition, Aes-ni is now available with CPU support, and most x86 processors produced over the past three or four years are supported.

On Linux, if you execute grep ^flags/proc/cpuinfo | Grep-w AES finds any matching results, which means that your system supports AES-NI. However, virtual machine hypervisor, such as VMware or VirtualBox, may hide the real capabilities of the CPU for the client operating system, including Aes-ni.

The interesting result of enabling Aes-ni is that the addition and decryption of industrial strength, such as aes128-gcm-sha256, is now much faster than the unencrypted cipher such as NULL-MD5!

Reduce the stress response of garbage collection

One side effect of multi-story refactoring is that it greatly reduces the number of persistent handles in the Node.js core.

A persistent handle is a strong reference to an object on the V8 heap, preventing the object from being reclaimed by the garbage collector before the reference is removed again (as GC says, it is an artificial GC root.) ）

Node.js uses persistent handles to cache values that are often used, such as strings or object prototypes. However, the persistent handle requires a special post processing step in the garbage collector and a linear growth overhead based on the number of handles.

Because of the effect of multiple scenarios cleanup, most persistent handles are either eliminated or switched to a lighter weight mechanism (called an ' eternity handle '), what does the name imply? ）

The end result is that your program uses less time inside the garbage collector to spend more time on actual work. Now in the output of node–prof v8::internal::globalhandles::P ostgarbagecollectionprocessing () should appear a lot less often.

Better cluster performance

Node.js v0.10 's cluster module relies on the operating system to distribute access connections evenly to worker processes.

It turns out that on Solaris and Linux, some workloads are unevenly distributed among worker processes. In order to alleviate this situation, Node.js v0.12 has been changed, using the rotation method by default. This article is described in more detail.

Faster timers, Faster setimmediate (), Faster Process.nexttick ()

SetTimeout () and its friends are now using a time source that is not only faster, but also immune to clock offsets. This optimization is enabled on all platforms, but on Linux we go further and read the current time directly from the VDSO, thus greatly reducing the number of gettimeofday (2) and Clock_gettime (2) system calls.

Setimmediate () and Process.nexttick () also add a quick path to the usual distribution, and can see performance adjustments. This means that although these functions are already pretty fast, they are now faster.