mlconnor

yaml = require('js-yaml');
fs   = require('fs');
Handlebars = require('hbs');

Handlebars.registerHelper("sep", function(options){
    if(options.data.last) {
        return options.inverse();
    } else {
        return options.fn();
    }

mlconnor

//
// Regular Expression for URL validation
//
// Author: Diego Perini
// Updated: 2010/12/05
// License: MIT
//
// Copyright (c) 2010-2013 Diego Perini (http://www.iport.it)
//
// Permission is hereby granted, free of charge, to any person

mlconnor

var request = require('request');
var async = require('async');

var url = "...";
var payload = "...";

var calls = [];
var clients = 100;
var callsPerClient = 20;
var thinkTime = 0;

mlconnor

Session Management in an Autoscaling Environment

Problem Statement

User sessions in J2EE and LAMP stacks have traditionally been handled in memory by the application server handling the user request. Because of that, load balancers have been configured to use sticky sessions. By sticky sessions we mean that once the user has visited the site, they will be assigned an app server and will return to that server for subsequent requests. The load balancers typically handle that by referencing the users session cookie.

Elastic cloud environments differ from traditional server configurations in that they have a variable number of servers based on traffic loads whereas traditional configurations had a fixed number of servers. When traffic volumes decline it is necessary to vaporize servers. In doing so, we would lose user sessions (essentially forcing a logout) unless we come up with a new strategy for session management.

A new approach

After much research, it is clear that the best

mlconnor

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl rsa -in server.key -out server.key
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

mlconnor

Elastic Beanstalk Java JVM Settings

Determining the right memory settings (MX & MS) for the JVM is not trivial. If you set memory too low then your machine will trash as it runs out and eventually crash. If you set it too high then other critical processes such as Apache or the OS itself may become memory starved and also cause crashes.

In general, I think it best to set the initial memory setting (MS) to be small, around 200M. The real variable we need to calculate is the limit we will place on JVM memory (MS).

In order to make this determination, we need to calculate a few things such as the memory that Apache and the Linux OS need to operate efficiently.

Apache Memory Needs

mlconnor

Good basic intro on types
https://docs.python.org/2/tutorial/introduction.html
https://docs.python.org/2/tutorial/controlflow.html

blocks use : and indent

while a < b:
  print a
  
if x < 0:

mlconnor

function arr2csv(arr) {
  var cols = [];
  /* get a list of unique columns */
  _.each(arr, function(item) {
    cols = _.union(_.keys(item), cols);
  });
  var csvRows = [cols.join("\t")];

  for ( var i = 0; i < arr.length; i++ ) {
    var row = arr[i];

mlconnor

list nodes_to_visit = {root};
while( nodes_to_visit isn't empty ) {
  currentnode = nodes_to_visit.first();
  nodes_to_visit.prepend( currentnode.children );
  //do something
}

BFS:

list nodes_to_visit = {root};

mlconnor

function request2Curl(options) {
  var tokens = ['curl', '-v', '-k', '-ssl3'];

  if ( _.has(options, 'auth') ) {
    if ( _.has(options.auth, 'user') ) {
      tokens.push('--user', "'" + options.auth.user + ":" + options.auth.pass + "'");
    }
  }

  var isPost = _.has(options, 'method') && options.method.toLowerCase() == 'post';