From the Blogosphere
Effects of Omitting NODE_ENV in Express.js Apps By @DKhan | @DevOpsSummit #APM #DevOps
Environment variables are often used for distinguishing between environments like 'production,' 'staging' and 'development'
By: Daniel Khan
Aug. 2, 2015 01:00 PM
The Drastic Effects of Omitting NODE_ENV in Your Express.js Applications
Most developers learn best by examples, which naturally tend to simplify matters and omit things that aren't essential for understanding. This means that the "Hello World" example, when used as starting point for an application, may be not suitable for production scenarios at all.
I started using Node.js like that and I have to confess that it took me almost two years to quantify the huge performance impact of omitting a single environment variable. In fact it was just a coincidence that I even did it right in my previous projects.
Mind your environment
In Node.js there is a convention to use a variable called NODE_ENV to set the current mode.
For my Node.js projects I mostly use Express.js, a lightweight web application framework. If you look at its Hello World example you might think Express doesn't care about the mentioned NODE_ENV variable because there is no reference to it. However, a look at the source code tells a slightly different story. We see that it in fact reads NODE_ENV and defaults to ‘development' if it isn't set. This variable is exposed to applications via ‘app.get("env")' and can be used to apply environment specific configurations as explained above, but it's up to you to use this or not.
One strength of Node.js is its module ecosystem, and a typical application uses plenty of them. For Express I always at least install a template engine which can be easily added to a project. You see that there is no further configuration needed. It just works out-of-the-box. And basically this is where the trouble starts.
The hidden powers of NODE_ENV
In my applications I always used some conditions that relied on the "env" variable, so I launched them with something like NODE_ENV=<environment> node server.js. But what would happen if I didn't? Would there be a notable performance hit?
This means: open this webpage 10.000 times with a concurrency of 100.
Using Dynatrace Web I charted the number of requests versus CPU usage and the results were really stunning:
Figure 2: CPU Usage vs. Number of Requests
The green bars show the number of requests and the blue line represents the CPU usage. We clearly see that by setting NODE_ENV to production the number of requests Node.js can handle jumps by around two-thirds while the CPU usage even drops slightly.
Let me emphasize this: Setting NODE_ENV to production makes your application 3 times faster!
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week