Pete Hunt petehunt

## Redis_in_Production_at_Smyte.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                petehunt
                / Redis_in_Production_at_Smyte.md
            
            
              Created
              October 7, 2016 08:12
            
          
    Redis in Production at Smyte

To be clear we continue to run many Redis services in our production environment. It’s a great tool for prototyping and small workloads. For our use case however, we believe the cost and complexity of our setup justifies urgently finding alternate solutions.

Each of our Redis servers are clearly numbered with a current leader in one availability zone, and a follower in another zone.
The servers run ~16 different individual Redis processes. This helps us utilize CPUs (as Redis is single-threaded) but it also means we only need an extra 1/16th memory in order to safely perform a BGSAVE (due to copy-on-write), though in practice it’s closer to 1/8 because it’s not always evenly balanced.
Our leaders do not every run BGSAVE unless we’re bringing up a new slave which is carefully done manually. Since issues with the slave should not affect the leader and new slave connections might trigger an unsafe BGSAVE on the leader, slave Redis processes are set to not automatically rest


## gist:8595248

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                petehunt
                / gist:8595248
            
            
              Created
              January 24, 2014 10:43
            
          
    It looks like ReactDefaultPerf found some places you could add shouldComponentUpdate(). Great!
Keep in mind that just because there are lots of items in the table does not mean you need to add lots of shouldComponentUpdate() methods. Instead, simply try adding one to the highest-ranked component in the table and re-running the perf test. Often you'll see that it takes care of the other components on the list automatically for you.
For more information about shouldComponentUpdate() see http://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate

  
## gist:8396968
macro := {
  rule infix { $obj $([ $key ] ...) | $rval:expr } => {
    $obj = mori.assoc_in($obj, [$key (,) ...].reverse(), $rval)
  }
}

macro hash_map {
  rule {{ $($key : $value) (,) ... }} => {
    mori.hash_map($($key, $value) (,) ...)
  }

## gist:8378115
function ObservableProperty(obj, key) {
  this.obj = obj;
  this.key = key;
}

ObservableProperty.prototype.get = function() {
  return this.obj.get(this.key);
};

ObservableProperty.prototype.addObserver = function(target, method) {

## gist:7979935
    var graph = new MoriModel();

    expect(graph.getNode('mykey')).toBe(null);
    graph.addNode('mykey', mori.hash_map('name', 'myvalue'));
    expect(
      mori.equals(graph.getNode('mykey'), mori.hash_map('name', 'myvalue'))
    ).toBe(true);

    graph.addNode('mykey2', mori.hash_map('name', 'myvalue2'));
    graph.addEdge('friends', 'mykey', 'mykey2');

## gist:7618353
First of all, I have an experimental branch with React that lets you use compile CSS animations just-in-time with our reconciliation system and use those instead of pure JS. So I recognize that they should be supported.

In my experience CSS transitions and animations work fine for things that will always animate fully and will never have the animation changed. A good example is a fade out when deleting a list item.

I've just found that in my own work most animations are tied with direct user touch manipulation (like animating out the left nav w/ parallax and opacity) which requires frame-by-frame responsiveness to touch events and inertia calculations based on the user's touch velocity. It's impossible to do this without doing frame-by-frame.

Your skepticism is definitely warranted and I complain to browser vendors whenever I see them about this. In my experience, modern (1 year old) phones can do this with minimal jank but there can still be issues. Assuming you're already avoiding reflows, here are the

## gist:6789788
// component with layout
var Link = React.createClass({
  mixins: [LayoutMixin]

  render: function () {
    <span>
      {this.props.children[0]}
      {this.transferPropsTo(<a>{this.props.children[1]}</a>)}
      {this.props.children[2]}
    </span>

## gist:6689857
/** @jsx React.DOM */

var Hello = React.createClass({
    mixins: [LinkedStateMixin],
    getInitialState: function() {
        return {name: 'phunt'};
    },
    render: function() {
        return (
          <div>

## gist:6601468
<html>
  <head>
    <title>wtf</title>
  </head>
  <body>
    yolo
    <script>
      window.addEventListener('mousemove', function() {}, false);
    </script>
  </body>

## gist:6601475
<html>
  <head>
    <title>wtf</title>
  </head>
  <body>
    yolo
    <script>
      window.addEventListener('mousemove', function() {}, false);
    </script>
  </body>
	macro := {
	rule infix { $obj $([ $key ] ...) \| $rval:expr } => {
	$obj = mori.assoc_in($obj, [$key (,) ...].reverse(), $rval)
	}
	}

	macro hash_map {
	rule {{ $($key : $value) (,) ... }} => {
	mori.hash_map($($key, $value) (,) ...)
	}
	function ObservableProperty(obj, key) {
	this.obj = obj;
	this.key = key;
	}

	ObservableProperty.prototype.get = function() {
	return this.obj.get(this.key);
	};

	ObservableProperty.prototype.addObserver = function(target, method) {
	var graph = new MoriModel();

	expect(graph.getNode('mykey')).toBe(null);
	graph.addNode('mykey', mori.hash_map('name', 'myvalue'));
	expect(
	mori.equals(graph.getNode('mykey'), mori.hash_map('name', 'myvalue'))
	).toBe(true);

	graph.addNode('mykey2', mori.hash_map('name', 'myvalue2'));
	graph.addEdge('friends', 'mykey', 'mykey2');
	First of all, I have an experimental branch with React that lets you use compile CSS animations just-in-time with our reconciliation system and use those instead of pure JS. So I recognize that they should be supported.

	In my experience CSS transitions and animations work fine for things that will always animate fully and will never have the animation changed. A good example is a fade out when deleting a list item.

	I've just found that in my own work most animations are tied with direct user touch manipulation (like animating out the left nav w/ parallax and opacity) which requires frame-by-frame responsiveness to touch events and inertia calculations based on the user's touch velocity. It's impossible to do this without doing frame-by-frame.

	Your skepticism is definitely warranted and I complain to browser vendors whenever I see them about this. In my experience, modern (1 year old) phones can do this with minimal jank but there can still be issues. Assuming you're already avoiding reflows, here are the
	// component with layout
	var Link = React.createClass({
	mixins: [LayoutMixin]

	render: function () {
	<span>
	{this.props.children[0]}
	{this.transferPropsTo(<a>{this.props.children[1]}</a>)}
	{this.props.children[2]}
	</span>
	/** @jsx React.DOM */

	var Hello = React.createClass({
	mixins: [LinkedStateMixin],
	getInitialState: function() {
	return {name: 'phunt'};
	},
	render: function() {
	return (
	<div>
	<html>
	<head>
	<title>wtf</title>
	</head>
	<body>
	yolo
	<script>
	window.addEventListener('mousemove', function() {}, false);
	</script>
	</body>