ryandotsmith

Process Partitioning

The Problem

When working with large, high volume, low latency systems, it is often the case that processing data sequentially becomes detrimental to the system's health. If we only allow 1 process to work on our data we run into several challenges:

• Our process may fall behind resulting in a situation which it is impossible for our process to catch up.
• Our singleton process could crash and leave our system in a degraded state.
• The average latency of data processing could be dramatically affected by outlying cases.

ryandotsmith

Event Buffering

Eventually platforms outgrow the single-source-tree model and become distributed systems. A common pattern in these distributed systems is distributed composition via event buffering. Here we motivate and describe this event buffering pattern.

The Problem

ryandotsmith

The Worker Pattern

Contents

• Introduction
• Definition
• Examples
• Links

Introduction

jcasimir

Measuring Performance

Performance is often ignored in Rails development until it becomes a problem. If ignored too long, though, it can get very tricky to improve. It's valuable to regularly audit performance and look for hotspots or design choices that are slowing things down.

Inspecting the Logs

Inspecting the log will help identify the source of several performance issues the application may have.

The Rails application log outputs the time spent processing each request. It breakdowns the time spent at the database level as well processing the view code. In development mode, the logs are displayed on STDOUT where the server is being run. In a production setting the logs will be in log/production.log within the application's root directory.

jcasimir

Exposing an API

APIs are becoming an essential feature of modern web applications. Rails does a good job of helping your application provide an API using the same MVC structure you're accustomed to.

In the Controller

Let's work with the following example controller:

class ArticlesController < ApplicationController

jcasimir

Sessions and Conversations

HTTP is a stateless protocol. Sessions allow us to chain multiple requests together into a conversation between client and server.

Sessions should be an option of last resort. If there's no where else that the data can possibly go to achieve the desired functionality, only then should it be stored in the session. Sessions can be vulnerable to security threats from third parties, malicious users, and can cause scaling problems.

That doesn't mean we can't use sessions, but we should only use them where necessary.

Adding, Accessing, and Removing Data

sirupsen

# requires root permissions in /usr/bin/

star = String.new
8.times { star += "*" }
Star = "\n#{star * 3}\n"

def newblock string
    puts "\n#{Star}#{string}#{Star}\n"
end

jcasimir

Controller Filters

The Rails REST implementation dictates the default seven actions for your controllers, but frequently we want to share functionality across multiple actions or even across controllers. Controller filters are the easiest way to do that.

Before, After, and Around

There are three types of filters implemented in Rails:

• a before_filter runs before the controller action
• an after_filter runs after the controller action

jcasimir

Handling Parameters

The controller's job is to work with the request parameters and determine how to activate the domain logic and data to respond to requests. The parameters are key to completing that job.

And, at the same time, parameters are the cause of the most problems in a typical controller. A great action method should be about eight lines of Ruby, but many actions spiral out of control with all kinds of switching based on the input parameters.

params Helper

First, a small point of order: people commonly refer to params as a variable but it isn't -- it is a helper method provided by ActionController which returns a hash containing the request parameters.

jcasimir

Transactions

As your business logic gets complex you may need to implement transactions. The classic example is a bank funds transfer from account A to account B. If the withdrawal from account A fails then the deposit to account B should either never take place or be rolled back.

Basics

All the complexity is handled by ActiveRecord::Transactions. Any model class or instance has a method named .transaction. When called and passed a block, that block will be executed inside a database transaction. If there's an exception raised, the transaction will automatically be rolled back.

Example