Daniel Khan

Subscribe to Daniel Khan: eMailAlertsEmail Alerts
Get Daniel Khan: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Application Performance Management (APM), DevOps Journal

Blog Post

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'

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
Environment variables are often used for distinguishing between environments like "production", "staging" and "development". Depending on those variables an application may turn debugging on or off, connect to a specific database, or listen on a specific port.

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
While you might think that you are environment-agnostic by not using NODE_ENV or app.get(‘env'), Express takes care of that for you and will for instance switch the view cache on or off depending on your environment. This makes sense because you don't want to restart your app to clear the cache every time you change some markup. Consequently this also means that your views are parsed and rendered for every request in development mode. Do you remember that this is the default if you omit 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?

Let's test
I've created a little sample app that connects to a database, calls some external services and renders a page using Jade.

After instrumenting it using Dynatrace I ran several tests using theapache benchmarking tool (ab) like that: ab -c 100 -n 10000 http://<myhostname>:3000/

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!

Click here for the full article

More Stories By Daniel Khan

Daniel Khan has over 15 years experience as full stack developer, architect and technical lead in the field of web engineering proving his strong problem solving skills in hundreds of projects. He is passionate about constant learning, using new technologies and sharing his findings with others. As technology strategist, Daniel focuses on driving support for emerging technologies like Node.js and MongoDB at Dynatrace.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.