Search

Todd Rodzen

Agile Application Development

Tag

node.js

UUID vs Auto Increment

What is the best method to create a key in today’s advanced Javascript node.js style applications? Do you rely on the old tried and true method to use auto-increment on the database primary key? or is a UUID better? One thought to help answer that; is a sequential key useful? Especially in the situation where the unique key may start out as only in the application or only on the client session store (ie. Redis key memory store.) In this situation, a sequential key is not useful and creating the auto increment key takes an additional step using INCR on Redis or INSERT on MySQL which could also create an unnecessary round trip to your database.

On the other hand, the UUID v4 implementation which creates a unique randomized UUID may appear to be a CPU time slice consuming operation, but one stackoverflow user did some testing, as posted here,:

uuid.png

You can see the green and yellow lines of increased connections. As connections increase AUTO INCR method creates an increased latency; while the UUID is a steady same or lower process time slice.

I didn’t come up with this one but found it may possibly be the smallest UUID v4 generator code.

exports.uuid = function b(a){return a?(a^Math.random()*16>>a/4).
   toString(16):([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g,b)}

There is no one answer. It’s always good to have multiple available methods but be sure to consider the uses and weigh the options.

Redis Cluster with Passwords

Do a little work with Redis Clusters and you will see in multiple places developers trying to get Redis node instances with passwords to work in a Redis cluster environment. The fact is it’s not supported. It’s not an option for good reason. There is a second back data channel that essentially makes the password AUTH meaningless. On top of that, passwords on a memory key store is well, meaningless for a good hacker. If you can throw thousands of passwords at the instance in ONE SECOND then the brute force hack is pretty easy. Maybe future versions of Redis will start to take password retries into consideration.

On the other hand, there are good reasons for a password on any service. A couple reasons come to mind: 1. You simply want to stop inadvertent prying eyes, such as an employee within the company that has access to the machine and the redis-cli command tool. 2. Maybe you post your passwords on a sticky note next to the computer room monitor so the password itself is not a concern but the person that has access to the machine but not the computer room should be staying out of the data. 3. You have multiple people that work on the machine and you want to protect your instance so a co-developer doesn’t accidently access and delete your Redis node. The list could probably go on much longer. One thing for sure, even if you assign a password to your Redis instance if you open the port up to the public you are opening yourself up to a hack. On the other hand, if it has a password and you are only using it for testing and development, maybe it’s not a big deal.  The better option is to use SSH to tunnel to your Redis server over the internet. That has its own issues.

One reason I chose to setup a cluster with AUTH passwords is I wanted to build apps on my laptop running locally on my laptop node.js server. I want the app to connect to my remote MYSQL development/production database and the same type of situation for the memory key store. That way, in theory, you can develop and test a version on the laptop. You can push it to the development EC2 server without any code changes and it should also work because it would be using the same MYSQL database (connecting to hostname mysql.mydomain.com) and Redis Cluster connection to a hostname redis.mydomain.com. (it won’t be using a local cluster or node on my laptop during development.)

With a Redis cluster environment, there is a back channel communications port for the cluster for each Redis node instance. The communications port is the node’s port with a 1 in front of the number. So if you have a node sitting on port 6101 there is also a back channel cluster communications port of 16101. We don’t use it. It’s only used by the Redis server. So In my situation above, I will not open the communications port to the public.

six-node-redis-cluster

Furthermore, why go to all this trouble if you are just working on a development application. Well, in theory, your development application will soon be a minimum viable product (MVP) and that won’t happen, or be much more difficult later, if you develop an application with code using a single memory store environment and then have to transition to a whole new API client for production. It’s better to develop an application once the right way. If you are developing an application that will have widespread use you know the cluster environment is needed. It may be a question of your development process and some won’t want to take this approach. But if you develop with a single node you might expect a multi-stage redevelopment as clusters are needed down the road and that adds a few steps.

With my development scenario, I am using the same server for all six nodes with 3 masters and 3 slaves. Again it’s not needed unless you start moving these nodes to additional EC2 instances or your application usage grows to handle the larger demand. With this design you can always add additional nodes later without application coding changes.

So here are the steps to create the cluster:

  1. create a minimum 6 Redis node instances with different hosts or ports using the following changes to the Redis conf file. To do this I created a /redis/data directory and copied the initial install 6379.conf file to the new port name in the /etc/redis directory. Then change each with the following
    port 6101
    
    pidfile /redis/data/redis_pid_6101.pid
    logfile /redis/data/redis_log_6101.log
    
    dbfilename dump_6101.rdb
    appendfilename "appendonly_6101.aof"
    cluster-config-file nodes_6101.conf
    
    requirepass myWickedLong256CharacterHashPassword
    
    dir /redis/data
    
    protected-mode no
    appendonly yes
    cluster-enabled yes
    
    # USE CLUSTER SYS INSTALL DEFAULTS BELOW
    cluster-node-timeout 15000
    cluster-slave-validity-factor 10
    cluster-migration-barrier 1
    cluster-require-full-coverage yes
    
    # USE OTHER SYS INSTALL DEFAULTS

    * create a .conf file for each port 6101 – 6106

  2. start each node with the redis-server command
    /usr/local/bin/redis-server /etc/redis/6101.conf

    * start each port 6101 – 6106

  3. Now we need to hack the redis-trib.rb progam with the following changes:
    This code change starts around line 57 and goes to line 125. You can cut, copy, and past as long as you get the exact same section of code (using Redis version 3.2.6) or simply scan through my code for the lines added and changed that are tagged with # tlr <start/end> comments

    class ClusterNode
     def initialize(addr)
     s = addr.split(":")
     if s.length < 2  puts "Invalid IP or Port (given as #{addr}) - use IP:Port format"  exit 1  end # tlr start pwd = nil  if s.length == 3  pwd = s.pop  end # tlr end port = s.pop # removes port from split array  ip = s.join(":") # if s.length > 1 here, it's IPv6, so restore address
     @r = nil
     @info = {}
     @info[:host] = ip
     @info[:port] = port
     @info[:slots] = {}
     @info[:migrating] = {}
     @info[:importing] = {}
     @info[:replicate] = false
    
    # tlr start
    @info[:password] = pwd 
    # tlr end
    
    @dirty = false # True if we need to flush slots info into node.
     @friends = []
     end
    
    def friends
     @friends
     end
    
    def slots
     @info[:slots]
     end
    
    def has_flag?(flag)
     @info[:flags].index(flag)
     end
    
    def to_s
     "#{@info[:host]}:#{@info[:port]}"
     end
    
    def connect(o={})
     return if @r
     print "Connecting to node #{self}: " if $verbose
     STDOUT.flush
     begin
    
    # tlr start
     if @info[:password] != nil
     @r = Redis.new(:host => @info[:host], :port => @info[:port], :timeout => 60, :password=>@info[:password])
     @r.ping
     else
     @r = Redis.new(:host => @info[:host], :port => @info[:port], :timeout => 60)
     @r.ping
     end
    # tlr end (the 2 lines in the else section are not changed from original)
    
    rescue
     xputs "[ERR] Sorry, can't connect to node #{self}"
     exit 1 if o[:abort]
     @r = nil
     end
     xputs "OK" if $verbose
     end
  4. next run the redis-trib.rb program to combine your nodes into one cluster. This may be a super long command from the command line especially if you have 256 character passwords but it works. (do it all on one line)
    /redis/redis-3.2.6/src/redis-trib.rb create --replicas 1 
    127.0.0.1:6101:my256charPassword 127.0.0.1:6102:my256charPassword 
    127.0.0.1:6103:my256charPassword 127.0.0.1:6104:my256charPassword 
    127.0.0.1:6105:my256charPassword 127.0.0.1:6106:my256charPassword

    * I did notice this produced a few errors as shown below but they are simply the process verification errors and the nodes are working fine.

    >>> Creating cluster
    >>> Performing hash slots allocation on 6 nodes...
    Using 3 masters:
    127.0.0.1:6101
    127.0.0.1:6102
    127.0.0.1:6103
    Adding replica 127.0.0.1:6104 to 127.0.0.1:6101
    Adding replica 127.0.0.1:6105 to 127.0.0.1:6102
    Adding replica 127.0.0.1:6106 to 127.0.0.1:6103
    
    (slot master/slave identifiers)
    
    Can I set the above configuration? (type 'yes' to accept): yes
    >>> Nodes configuration updated
    >>> Assign a different config epoch to each node
    >>> Sending CLUSTER MEET messages to join the cluster
    Waiting for the cluster to join.....
    [ERR] Sorry, can't connect to node 127.0.0.1:6105
    [ERR] Sorry, can't connect to node 127.0.0.1:6106
    [ERR] Sorry, can't connect to node 127.0.0.1:6103
    [ERR] Sorry, can't connect to node 127.0.0.1:6102
    [ERR] Sorry, can't connect to node 127.0.0.1:6104
    >>> Performing Cluster Check (using node 127.0.0.1:6101)
    M: 4f531ed4bcfd058b688a8692138fbdcc01a9dc7e 127.0.0.1:6101
     slots:0-5460 (5461 slots) master
     0 additional replica(s)
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [ERR] Not all 16384 slots are covered by nodes.

    A few more edits would fix the warning errors. 🙂 Since this is a one time command to initially setup your cluster, it’s not an issue. To add nodes to your existing cluster in the future you will user the rediscli command line tool with the CLUSTER MEET command.

  5. Confirm the cluster is working with the rediscli command setting a value.
    /usr/local/bin/redis-cli -c -p 6101 -a my256CharPassword
    SET foo bar
    GET foo
    CLUSTER SLOTS
    CLUSTER INFO

    You might notice foo gets pushed to a slot on the 2nd master. try SET a a and then try SET z z. You can also connect to any of the six nodes (6101 – 6106) to verify the sets with a GET command. (GET foo)

That’s all there is to it. You can open the 6101 – 6106 port to your local laptop and start developing on your local machine using the node.js ioredis client package on NPM at https://www.npmjs.com/package/ioredis

ps. Of course that’s not all! 🙂 additional code changes would be needed for example the slave to master login with AUTH.

Redis Session and MySQL Login

The following does a Redis session store and MySQL user register and login as well as a simple message post. This is run on a node.js server

package.json

{
 "name": "users",
 "version": "1.0.0",
 "description": "Register User",
 "main": "app.js",
 "script": "./app.js",
 "watch": true,
 "ignore_watch": ["node_modules"],
 "keywords": [
"login"
 ],
 "author": "Todd Rodzen",
 "license": "MIT",
 "dependencies": {
 "async": "^1.2.1",
 "body-parser": "^1.13.0",
 "connect-redis": "^2.3.0",
 "cookie-parser": "^1.3.5",
 "ejs": "^2.3.1",
 "express": "^4.14.0",
 "express-session": "^1.11.3",
 "mysql": "^2.7.0",
 "redis": "^0.12.1"
 }
}

app.js

/**
 Loading all dependencies.
**/
var express = require("express");
var redis = require("redis");
var mysql = require("mysql");
var session = require('express-session');
var redisStore = require('connect-redis')(session);
var bodyParser = require('body-parser');
var cookieParser = require('cookie-parser');
var path = require("path");
var async = require("async");
var client = redis.createClient();
var app = express();
var router = express.Router();

// Always use MySQL pooling.
// Helpful for multiple connections.

var pool = mysql.createPool({
 connectionLimit : 100,
 host : 'hmmmmm',
 user : 'you',
 password : 'ssshhhhh',
 database : 'hmmmm',
 debug : false
});

app.set('views', 'view');
app.engine('html', require('ejs').renderFile);

// IMPORTANT
// Here we tell Express to use Redis as session store.
// We pass Redis credentials and port information.
// And express does the rest ! 

app.use(session({
 secret: 'topics-session',
 store: new redisStore({ host: 'localhost', port: 6379, client: client,ttl : 260}),
 saveUninitialized: false,
 resave: false
}));
app.use(cookieParser("secretSign#143_!223"));
app.use(bodyParser.urlencoded({extended: false}));
app.use(bodyParser.json());

// This is an important function.
// This function does the database handling task.
// We also use async here for control flow.

function handle_database(req,type,callback) {
 async.waterfall([
 function(callback) {
 pool.getConnection(function(err,connection){
 if(err) {
 // if there is error, stop right away.
 // This will stop the async code execution and goes to last function.
 callback(true);
 } else {
 callback(null,connection);
 }
 });
 },
 function(connection,callback) {
 var SQLquery;
 switch(type) {
 case "login" :
 SQLquery = "SELECT * from user_login WHERE user_email='"+req.body.user_email+"' AND `user_password`='"+req.body.user_password+"'";
 break;
 case "checkEmail" :
 SQLquery = "SELECT * from user_login WHERE user_email='"+req.body.user_email+"'";
 break;
 case "register" :
 SQLquery = "INSERT into user_login(user_email,user_password,user_name) VALUES ('"+req.body.user_email+"','"+req.body.user_password+"','"+req.body.user_name+"')";
 break;
 case "addStatus" :
 SQLquery = "INSERT into msg_text(user_id,msg_text) VALUES ("+req.session.key["user_id"]+",'"+req.body.status+"')";
 break;
 case "getStatus" :
 SQLquery = "SELECT * FROM msg_text WHERE user_id="+req.session.key["user_id"];
 break;
 default :
 break;
 }
 callback(null,connection,SQLquery);
 },
 function(connection,SQLquery,callback) {
 connection.query(SQLquery,function(err,rows){
 connection.release();
 if(!err) {
 if(type === "login") {
 callback(rows.length === 0 ? false : rows[0]);
 } else if(type === "getStatus") {
 callback(rows.length === 0 ? false : rows);
 } else if(type === "checkEmail") {
 callback(rows.length === 0 ? false : true);
 } else {
 callback(false);
 }
 } else {
 // if there is error, stop right away.
 // This will stop the async code execution and goes to last function.
 callback(true);
 }
 });
 }],
 function(result){
 // This function gets call after every async task finished.
 if(typeof(result) === "boolean" && result === true) {
 callback(null);
 } else {
 callback(result);
 }
 });
}

/**
 --- Router Code begins here.
**/

router.get('/',function(req,res){
 res.render('index.html');
});

router.post('/login',function(req,res){
 handle_database(req,"login",function(response){
 if(response === null) {
 res.json({"error" : "true","message" : "Database error occured"});
 } else {
 if(!response) {
 res.json({
 "error" : "true",
 "message" : "Login failed ! Please register"
 });
 } else {
 req.session.key = response;
 res.json({"error" : false,"message" : "Login success."});
 }
 }
 });
});

router.get('/home',function(req,res){
 if(req.session.key) {
 res.render("home.html",{ email : req.session.key["user_name"]});
 } else {
 res.redirect("/");
 }
});

router.get("/fetchStatus",function(req,res){
 if(req.session.key) {
 handle_database(req,"getStatus",function(response){
 if(!response) {
 res.json({"error" : false, "message" : "There is no status to show."});
 } else {
 res.json({"error" : false, "message" : response});
 }
 });
 } else {
 res.json({"error" : true, "message" : "Please login first."});
 }
});

router.post("/addStatus",function(req,res){
 if(req.session.key) {
 handle_database(req,"addStatus",function(response){
 if(!response) {
 res.json({"error" : false, "message" : "Status is added."});
 } else {
 res.json({"error" : false, "message" : "Error while adding Status"});
 }
 });
 } else {
 res.json({"error" : true, "message" : "Please login first."});
 }
});

router.post("/register",function(req,res){
 handle_database(req,"checkEmail",function(response){
 if(response === null) {
 res.json({"error" : true, "message" : "This email is already present"});
 } else {
 handle_database(req,"register",function(response){
 if(response === null) {
 res.json({"error" : true , "message" : "Error while adding user."});
 } else {
 req.session.key = response;
 res.json({"error" : false, "message" : "Registered successfully."});
 }
 });
 }
 });
});

router.get('/logout',function(req,res){
 if(req.session.key) {
 req.session.destroy(function(){
 res.redirect('/');
 });
 } else {
 res.redirect('/');
 }
});

app.use('/',router);

app.listen(4201,function(){
 console.log("I am running at 4201");
});

view/index.html (code)
https://github.com/trodzen/MySQL-Redis-Session-Register/blob/master/view/index.html

view/home.html (code)
https://github.com/trodzen/MySQL-Redis-Session-Register/blob/master/view/home.html

You will need a working Redis db structure and MySQL and the two files used on the select/update SQL statements.

Try it, it’s easy.
That’s All Folks!

AMI Build All-in-One

Full build process

  1. Create an EC2 Linux Instance base – Amazon Linux AMI 2016.09.1 (HVM), SSD Volume Type – ami-0b33d91d
  2. Install the LAMP Stack default Apache port set to 8080 as it will be served to an Nginx reverse proxy server on the same instance (Apache 2.4, MySQL, PHP 6.7)
  3. Install the MEAN Stack
  4. Install Nginx Reverse Proxy Server
  5. Install ColdFusion 2016 update 3 Server

The server is setup and available for Free with a service contract from GTK Solutions.

Lets Encrypt

The following is a re-post excerpt from Brennen Bearnes at https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-16-04 with great thanks!

Install Let’s Encrypt and Dependencies

Let’s Encrypt is a new Certificate Authority that provides an easy way to obtain free TLS/SSL certificates.

You must own or control the registered domain name that you wish to use the certificate with. If you do not already have a registered domain name, you may register one with one of the many domain name registrars out there (e.g. Namecheap, GoDaddy, etc.).

If you haven’t already, be sure to create an A Record that points your domain to the public IP address of your server. This is required because of how Let’s Encrypt validates that you own the domain it is issuing a certificate for. For example, if you want to obtain a certificate for example.com, that domain must resolve to your server for the validation process to work.

For more detail on this process, see How To Set Up a Host Name with DigitalOcean and How To Point to DigitalOcean Nameservers from Common Domain Registrars.

Although the Let’s Encrypt project has renamed their client to certbot, the name of the package in the Ubuntu 16.04 repositories is simply letsencrypt. This package will be completely adequate for our needs.

To install the package, type:

  • sudo apt-get install letsencrypt

The letsencrypt client should now ready to use on your server.

Retrieve Initial Certificate

Since nginx is already running on port 80, and the Let’s Encrypt client needs this port in order to verify ownership of your domain, stop nginx temporarily:

  • sudo systemctl stop nginx

Run letsencrypt with the Standalone plugin:

  • sudo letsencrypt certonly –standalone

You’ll be prompted to answer several questions, including your email address, agreement to a Terms of Service, and the domain name(s) for the certificate. Once finished, you’ll receive notes much like the following:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/your_domain_name/fullchain.pem. Your cert will expire
   on 2016-08-10. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Note the path and expiration date of your certificate, highlighted in the example output. Your certificate files should now be available in /etc/letsencrypt/your_domain_name/.

Configure Nginx for HTTPS

You’ll need to add some details to your Nginx configuration. Open /etc/nginx/sites-enabled/defaultin nano (or your editor of choice):

  • sudo nano /etc/nginx/sites-enabled/default

Replace its contents with the following:

/etc/nginx/sites-enabled/default
# HTTP - redirect all requests to HTTPS:
server {
        listen 80;
        listen [::]:80 default_server ipv6only=on;
        return 301 https://$host$request_uri;
}

# HTTPS - proxy requests on to local Node.js app:
server {
        listen 443;
        server_name your_domain_name;

        ssl on;
        # Use certificate and key provided by Let's Encrypt:
        ssl_certificate /etc/letsencrypt/live/your_domain_name/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your_domain_name/privkey.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

        # Pass requests for / to localhost:8080:
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://localhost:8080/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_cache_bypass $http_upgrade;
                proxy_redirect off;
        }
}

Exit the editor and save the file.

Check the configuration for syntax errors by typing:

  • sudo nginx -t

When no errors are detected, start Nginx again:

  • sudo systemctl start nginx

You can test your new certificate and Nginx configuration by visiting http://your_domain_name/ in your browser. You should be redirected to https://your_domain_name/, without any security errors, and see the “Hello World” printed by your Node.js app.

Set Up Let’s Encrypt Auto Renewal

Warning: You can safely complete this guide without worrying about certificate renewal, but you will need to address it for any long-lived production environment.

You may have noticed that your Let’s Encrypt certificate is due to expire in 90 days. This is a deliberate feature of the Let’s Encrypt approach, intended to minimize the amount of time that a compromised certificate can exist in the wild if something goes wrong.

The Let’s Encrypt client can automatically renew your certificate, but in the meanwhile you will either have to repeat the certificate retrieval process by hand, or use a scheduled script to handle it for you. The details of automating this process are covered in How To Secure Nginx with Let’s Encrypt on Ubuntu 16.04, particularly the section on setting up auto renewal.

Reverse proxy on node.js

A reverse proxy is an important part of the puzzle of a production application. The process is to create a reverse proxy Nginx server that interacts with the world and dishes out the requests from the user to a farm of back-end application node.js or Apache servers. The actual backend application server can be secured to only communicate with the reverse proxy server, therefore limiting its vulnerability to attacks.

The good thing about the agile application design is you don’t have to modify your code for reverse proxy except to understand different processes may want to be broken up to different servers or a farm of servers. Therefore creating small single use back-end applications is preferred over a single larger more complex back end server design that does everything in one process. For example serving email and user logins are certainly better designed by different application processes.

Another benefit of running a Nginx reverse proxy is the single reverse proxy can server applications and website from both Apache servers and node.js servers, therefore, mydomain.com might be served by the Apache server while mydomain.com/app might be served by the node.js server.

A Nginx based reverse proxy server is installed with the following:

sudo yum install nginx
sudo chmod 664 /etc/nginx/nginx.conf

Then use Filezilla to add the following lines to the location / {} directives in the /etc/nginx/nginx.conf file

location / {
 proxy_pass http://localhost:8080;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection 'upgrade';
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 }

location /node {
 proxy_pass http://localhost:4200;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection 'upgrade';
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 }
Restart the Nginx reverse proxy server
sudo service nginx restart

Add auto start to the nginx service with

chkconfig nginx on

I prefer to start Nginx as a reverse proxy on port 80 and change the default root of httpd.conf to 8080 Therefore unless it’s a specifically defined location route it will default proxy through Nginx to the apache server.

That’s All.

to Cluster or not to Cluster

This blog will review cluster environment setup to handle node multi-threaded service instances. In our last post, we reviewed the methods of using pooled connections for MySQL connector in node.js on a Linux server running on an Amazon AWS EC2 instance. The conclusion was that it is necessary from the beginning of the application development process to write javascript back-end application server code that uses MySQL pooling methods. This is a significant change in the application code from the non-pooled connection method API. It is important to understand the techniques you intend to use before setting down to write your production code for a back-end application server because it’s important to write your application once and do it right the first time.

Now let’s take a look at clusters. This is a built-in part of the node.js methods. (We are not talking about the clusters add-on module from npmjs.com that goes by the same name.) Using the built in clusters methods for node.js is described in multiple blog posts here and here. The documentation and posts describe setting up a cluster.js that runs a master and fork process servers that run your app.js code multiple times utilizing multiple core processor threads. This increases throughput and creates a multi-threaded environment. The simplified node.js cluster environment code is shown here.

var cluster = require('cluster');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {

//  for (var i = 0; i < numCPUs; i++){
  for (var i = 0; i < 10; i++){
    cluster.fork();
  }

  cluster.on('exit',function(worker, code, signal) {
    console.log('worker ' + worker.process.pid + ' died');
  });
} else {

    //change this line to Your Node.js app entry point.
    require("./app.js");
}

In simplified terms, the code above creates multiple forks using a Master node cluster to run multiple instances (multi-threaded) of your node.js application. We did some testing on our Amazon AWS EC2 t2.micro (free tier) and using our async-test.js test, from our prior blog post, using an external RDS MySQL database with pooled MySQL connections. We used Siege of up to 500 concurrent connections and hit it constantly for 1 minute resulting in thousands of hits. What we found is a single process environment resulted in database connection errors while a cluster run environment of 10 processes (multi-threaded) running the same async-test resulted in no connection errors. This proves a cluster multi-threaded environment is important.

When you look at my code above you can see I altered the code to force 10 process forks (instead of using numCPUs.) Remember I am running this on a virtual shared server using Amazon AWS. When using the os.cpus ().length the os method reports back 1 core process thread.  This is the number of process threads available as designed by AWS. But a little digging into the full array results of the os.cpus () method reveals my AWS t2.micro is actually running on a XEON E5 2670 2.5ghz processor with 10 cores and 20 threads. If you did this on a single dedicated machine running that processor you would get a result of 20 for the os.cpus ().length method. Actually, Amazon does a lot of behind the scenes stuff to throttle the processes. But getting more than what you pay for is not at issue here. (Even though you may be getting it all for free through the free tier.) The issue is a working production application design that doesn’t fail at critical points like peak database traffic. So what we found is the processor even on the AWS t2.micro (free tier) was able to better handle the traffic on multiple clustered processes and it could handle a huge amount of traffic. One seige test resulted in no connection errors of over 8000 hits in 30 seconds. Since it is a shared server it is doubtful 20 threads would be useful. It’s interesting to note Amazon actually defines the t2.micro with 1 vCPU and 6 CPU credits/hour which is a throttle mechanism and different from actual core processing threads. Amazon uses processor credits to ensure you get what you pay for or to throttle your application as needed. As in life, you only get what you pay for! 🙂

But do we write code and change our application design to handle the cluster methods. No! We don’t change our code to use the cluster methods. There is a better way and it’s all handled for us using the PM2 module from npmjs.com. No need to create code like the cluster.js sample above. This multi-threading cluster environment, base node system control, monitoring, and performance optimization is likely a place where you don’t need to reinvent the wheel, there is already significant well-designed products to handle these functions. To start, just install the PM2 module with

npm install -g pm2

A useful additional tool in connection wth PM2 is the https://app.keymetrics.io dashboard monitor. You can go there and create a bucket and server connection to your PM2 server to generate metrics data and external monitoring and control. Use the PM2 documentation for all the PM2 commands but some of the useful commands are

Pm2 start app.js

Pm2 stop all

Pm2 start app.js -i 4  # to start 4 cluster instances of your app.js

Pm2 list  # to list all running process threads

There is another module called forever but we found PM2 is much more advanced, robust, and well supported.

One final item to do is setup PM2 to run on startup. Do the following command which creates a line item to copy and paste to your terminal window. The one line of code it creates will automatically start PM2 on reboot.

pm2 startup

What we do need to do in our application design is write good strong well-designed code that handles multiple instances running and save session or environment variables that can be accessed by all cluster process instances in a multi-threaded environment. In a later post we will cover using Redis as a global external store for process variables. As well codeforgeek provides a great tutorial. This is the real important part of application development. The two most important parts that must be designed to handle multi-threaded clusters and multi-instances are session like variables and database connection transactions. For example, three related SQL inserts or Redis store SETS must complete before another process tries to select that same and related set of data.

In conclusion, I recommend installing pm2 and use it from the start of the agile application development process. An added benefit of using pm2 in development is added logging and debugging methods.

to Pool or not to Pool

Using Node.js with MySQL Module I have done some testing. Under a real word situation stress on the server from multiple connections could result in a database connection failure. The answer is pooled connections. Here is my test code.

Non-pooled Connection

// test-sync.js
var express = require('express')
var app = express()

app.get('/test-sync', function (req, res) {
// console.log('1. Received Get')
 res.send('Hello World!')

var mysql = require('mysql');
var connection = mysql.createConnection({
 host : 'localhost',
 user : 'mazu',
 password : '',
 database : 'mazudb'
});
connection.connect(function(err){
if(!err) {
// console.log("2. Database Connected"); 
} else {
 console.log("Error connecting database ... nn"); 
}
});

sql="SELECT * FROM `test-mysql-Customers` LIMIT 2"
connection.query(sql, function(err, rows, fields) {
connection.end();
 if (!err) {
// console.log("3. SQL Completed");
} else
 console.log('Error while performing Query.');
 });
});

app.listen(4200, function () {
 console.log('Example app listening on port 4200!')
})

Pooled Connection

var express = require("express");
var mysql = require('mysql');
var app = express();

var pool = mysql.createPool({
 connectionLimit : 100, //important
 host : 'localhost',
 user : 'mazu',
 password : '',
 database : 'mazudb',
 debug : false
});

function handle_database(req,res) {
 
 pool.getConnection(function(err,connection){
 if (err) {
 res.json({"code" : 100, "status" : "Error in connection database"});
 var tlog = json({"code" : 100, "status" : "Error in connection database"});
 console.log(tlog);
 return;
 }

connection.setMaxListeners(0)

// console.log('connected as id ' + connection.threadId + ' connection.getMaxListeners()' + connection.getMaxListeners());
 
 sql="SELECT * FROM `test-mysql-Customers` LIMIT 2"

connection.query(sql,function(err,rows){
 connection.release();
 if(!err) {
 res.json(rows);
 } 
 });

connection.on('error', function(err) { 
 var tlog = json({"code" : 100, "status" : "Error in connection database"});
 console.log(tlog);
 res.json({"code" : 200, "status" : "Error in connection database"});
 return; 
 });
 });
}

app.get("/test-async",function(req,res){-
 handle_database(req,res);
});

app.listen(4200);

The primary difference between the two methods is the first one does a synchronous creatConnection, connect, query, and end; while the second pooled method does a createPool connection that creates a queue for the queries. When a get request is received it then does a getConnection that uses one process from the pooled process queue, it does its query, and finally a release of that one process in the pooled queue.

A stress test on these methods results in similar throughput. Essentially the same number of transactions can get through but with non-pooled connections, the likelihood of database connection errors is higher. I used a siege tool stress test with the following

siege -c200 -t60s -d3 http://localhost:4200/test-sync

It resulted in about 8000 hits but on the synchronous non-pooled method it resulted in about 16 database connection error, while the pooled method resulted in no connection errors. This test was with an Amazon EC t2.micro with Linux and an external RDS MySQL database. Obviously, database connection errors are bad! This proves a pooled connection is the way to go.

Express npm module

The Express module available from http://npmjs.com is a common tool to quickly build applications and can be used for back end node.js APIs. Let’s get started with Express on an Amazon Linux EC2 node.js server, do the following commands

mkdir -p -v /node/async-test && cd $_
npm init  # and answer the questions

npm install mysql --save
npm install express --save

Create the helloworld.js file in /node/async-test directory with the following Express module get and listen commands:

var express = require('express')
var app = express()

app.get('/helloworld', function (req, res) {
 res.send('Hello World!')
})

app.listen(4200, function () {
 console.log('Example app listening on port 4200!')
})

Run the node.js application with:

node helloworld.js

Now test at a web browser with:

http://myhost.amazonaws.com:4200/helloworld

The result on the web browser is Hello World! Go to http://expressjs.com/ for complete documentation on the Express module.

Powered by WordPress.com.

Up ↑