FooBarWidget

The point I was trying to make is that the differences look large because it's a hello world. I understand that you're benchmarking the overhead of the servers, but that doesn't mean anything until you compare the overhead to how much time the app itself needs.

The benefit of benchmarking the network is:

1. The overhead of the benchmarking program itself is not affecting the results.
2. It gives you a more realistic picture, because in production environments the network delays are significant. In fact, they should be so significant that the differences between the app servers should be greatly reduced.

Therefore, using Vagrant and VMs on the local machine will not work. You really have to benchmark over a network, using another computer. In my test I grabbed another laptop. You might want to spin up an EC2 instance.

A while ago we benchmarked Unicorn vs Passenger 4 over the network. The performance is almost identical: https://code.google.com/p/phusion-passenger/issues/detail?id=956#c4

FooBarWidget

$ sudo -H npm install -g [email protected]
npm http GET https://registry.npmjs.org/gulp/3.6.2
npm http 304 https://registry.npmjs.org/gulp/3.6.2
npm http GET https://registry.npmjs.org/archy
npm http GET https://registry.npmjs.org/chalk
npm http GET https://registry.npmjs.org/deprecated
npm http GET https://registry.npmjs.org/gulp-util
npm http GET https://registry.npmjs.org/liftoff
npm http GET https://registry.npmjs.org/orchestrator
npm http GET https://registry.npmjs.org/pretty-hrtime

FooBarWidget

<network>
  <name>default</name>
  <uuid>26f10cec-fe83-dc3f-2371-377c3c6b7028</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:2C:9D:26'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
      <host mac='A2:90:13:94:0F:13' name='ci.phusion.nl' ip='192.168.122.10' />

FooBarWidget

	private alpha (1 week):
	bruikbaar voor ons, maar nog niet voor serieuze doeleinden omdat we nog een server missen.
	- commando integreren: 2 dagen
	- AWS provider: 1 dag
	- andere dingen: 2

	public alpha (2.5 weken):
	- client packaging: 4 dagen
		- OS X: 1 dag
		- linux: 1 dag

FooBarWidget

554 5.7.1 Message cannot be accepted, content filter rejection REJECT - Body containing http.*\.nl (.nl TLD Spam)

FooBarWidget

import threading, traceback, signal, sys

def install_signal_handlers():
	def debug(sig, frame):
		id2name = dict([(th.ident, th.name) for th in threading.enumerate()])
		code = []
		for thread_id, stack in sys._current_frames().items():
			code.append("\n# Thread: %s(%d)" % (id2name.get(thread_id,""), thread_id))
			for filename, lineno, name, line in traceback.extract_stack(stack):
				code.append('  File: "%s", line %d, in %s' % (filename, lineno, name))

FooBarWidget

def boolean_option(name, default_value = false)
	value = ENV[name]
	if value.nil? || value.empty?
		return default_value
	else
		return value == "yes" || value == "on" || value == "true" || value == "1"
	end
end

#ENV['USE_ASAN'] = '1'

FooBarWidget

One example is that, by default, Unicorn requires 2x memory usage during a rolling restart. If you have 6 Unicorn worker processes, then during a rolling restart Unicorn will spawn another 6, and then replace the original 6 only after the new 6 have all been spawned. It is possible to perform rolling restart processes one-by-one (which requires dramatically less memory usage) but you have to write all sorts of configuration and scripts to do that.

As for the edge cases: what happens if something fails during a rolling restart? For example if there is a temporary network problem to the database server, causing a process to fail to spawn. Unicorn will not handle it properly, and will continue to kill off the old processes even though no new ones can be spawned, causing downtime.

Phusion Passenger Enterprise's rolling restart solves these issues nicely and elegantly. It does not require 2x memory usage, it does not require large scripts and configuration files, it does the right thing out of the box. It hand

FooBarWidget

# All times in this file are in UTC (GMT), not your local timezone.   This is
# not a bug, so please don't ask about it.   There is no portable way to
# store leases in the local timezone, so please don't request this as a
# feature.   If this is inconvenient or confusing to you, we sincerely
# apologize.   Seriously, though - don't ask.
# The format of this file is documented in the dhcpd.leases(5) manual page.

lease 172.16.210.236 {
	starts 2 2014/02/11 11:14:31;
	ends 2 2014/02/11 11:44:31;

FooBarWidget

 INFO global: Vagrant version: 1.4.3
 INFO global: Ruby version: 2.0.0
 INFO global: RubyGems version: 2.0.14
 INFO global: VAGRANT_DEFAULT_PROVIDER="vmware_fusion"
 INFO global: VAGRANT_LOG="debug"
 INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/Applications/Vagrant/bin/../embedded"
 INFO global: VAGRANT_INSTALLER_VERSION="2"
 INFO global: VAGRANT_DETECTED_OS="Darwin"
 INFO global: VAGRANT_INSTALLER_ENV="1"
DEBUG global: Loading core plugin: /Applications/Vagrant/embedded/gems/gems/vagrant-1.4.3/plugins/commands/box/plugin.rb