DEV Community: Jamie Gaskins

Docker Desktop Changes

Jamie Gaskins — Wed, 01 Sep 2021 21:54:37 +0000

Docker just updated their terms of use for Docker Desktop that requires a paid subscription for companies that have more than 250 employees or $10M in annual revenue. Some people have some feelings about this that I don’t quite understand. Can someone break it down for me?

I've Joined Forem as a Principal SRE

Jamie Gaskins — Thu, 04 Mar 2021 15:35:36 +0000

A couple of months ago, Molly reached out to let me know that an SRE role had opened up at Forem and asked if it was something I was interested in. At the time, I was a technical lead at Snapdocs, focusing on performance and stability of their service-oriented architecture. I was very much not ready to leave yet because there was still so much more work to do on that platform and so many things were really moving in a lot of the right directions. Why would I want to leave?

Well, I'd been keeping my eye on DEV as a company for the past couple of years now. My first interactions with folks on the team really showed their commitment to building a welcoming community, especially for folks who were new to software development. I mean, how awesome would it be to work with a team that was putting so much effort into building a tech-focused community that wants to build people up and actively works against people that would tear others down?

// Detect dark theme var iframe = document.getElementById('tweet-1095887827206893568-408'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1095887827206893568&theme=dark" }

And then DEV went open-source, the company rebranded into Forem, and grew from running a single website for a specific community into a platform to foster many communities. I really wanted to be a part of this. And since I've done a lot of open source for free and always wanted to work on open source for a living, the idea was that much more enticing.

With all that in mind, I didn't want to pass on an opportunity like this without at least exploring the idea, so I agreed to chat with Molly about it. I asked her approximately 16 million questions and she had great answers for all of them[1]. This made it a really difficult decision (I had two choices, and they were both great for various reasons), but I decided to take the plunge and come work on the Forem platform.

I'm really excited to see what I'll be able to accomplish here. The community is fantastic, my colleagues are fantastic (they're way cooler than I am, though, so I've gotta step up my game a bit), and there are a lot of fantastic problems to solve.

[1] One of my favorite responses from her was actually "we're still figuring that out if you'd like to help guide that process". If you're a hiring manager, that's a great response to a candidate's more difficult questions! It shows a culture of collaboration and selects for people who really enjoy the thing that that unfinished process involves.

Performance Comparison, Rust vs Crystal with Redis

Jamie Gaskins — Fri, 26 Jun 2020 13:45:18 +0000

You often hear about how fast languages like Rust and Go are. People port all kinds of things to Rust to make them faster. It's common to hear about a company porting a Ruby microservice to Go or writing native extensions for a dynamic language in Rust for extra performance.

Crystal also compiles your apps into blazing-fast native code, so today I decided to try comparing Rust and Crystal side-by-side in talking to a Redis database.

The Benchmark

I wanted something realistic, and most benchmarks I could find were things like Mandelbrot and digits of π. They're CPU-intensive, absolutely, but they're nothing like the workload a typical web app has.

The benchmark I went with was to connect to a Redis database and run a bunch of pipelined commands. Pipelining means we're sending all of the commands before reading any of them. Because we're not waiting for the result after sending each command, this drastically reduces the impact that latency has on the benchmark. For example, instead of this sequence:

Send command
Read result
Send command
Read result
Send command
Read result

What we do instead is this:

Send command
Send command
Send command
Read result
Read result
Read result

This way we pay the latency cost once between the last send and the first read instead of 3 times.

For our benchmark, we're going to run a mix of common Redis operations:

Set a key
Get a key that exists
Get a key that does not exist
Increment the value for a key

We do each of these 100k times. The more work we do in this pipeline, the less effect latency has and the more effective the benchmark is. The reason we run a mix of commands isn't so much about what Redis does with them (we're not benchmarking Redis), but what Redis returns for them. The SET and GET commands in Redis return strings, which require heap allocations. INCR returns an integer, which is usually allocated on the stack (no malloc / free needed) and doesn't necessarily require a heap allocation (though the implementation might parse the integer from an intermediate string, which could involve an allocation).

First we'll look at the code in each language, then the results.

Rust

We're using the redis-rs Rust crate for this app. We construct a Redis pipeline with redis::pipe(), fill it with data, and then send that data to the connection.

use redis::{self};
use std::time::{Instant};

fn main() {
    const ITERATIONS: usize = 100_000;
    let client = redis::Client::open("redis://127.0.0.1:6379").unwrap();
    let mut con = client.get_connection().unwrap();

    let start = Instant::now();
    let mut pipe = redis::pipe();

    pipe.del("foo").ignore();
    for _i in 0..ITERATIONS { pipe.set("foo", "bar").ignore(); }
    for _i in 0..ITERATIONS { pipe.get("foo").ignore(); }

    pipe.del("foo").ignore();
    for _i in 0..ITERATIONS { pipe.incr("foo", 1).ignore(); }

    pipe.del("foo").ignore();
    for _i in 0..ITERATIONS { pipe.get("foo").ignore(); }

    let () = pipe.query(&mut con).unwrap();

    println!("{}", start.elapsed().as_millis());
}

Crystal

require "../src/redis"

redis = Redis::Connection.new

start = Time.monotonic

iterations = 100_000
redis.pipeline do |redis|
  redis.del "foo"
  iterations.times { redis.set "foo", "bar" }
  iterations.times { redis.get "foo" }

  redis.del "foo"
  iterations.times { redis.incr "foo" }

  redis.del "foo"
  iterations.times { redis.get "foo" }
end

pp Time.monotonic - start

Note that this isn't the more common Crystal Redis shard. This is a Redis client I wrote that is significantly tuned to reduce heap allocations and remain light while supporting as much of Redis as I needed. ~~I will be publishing it on GitHub soon.~~ You can find the code on GitHub.

The Results

$ cargo run --release --example redis_app
    Finished release [optimized] target(s) in 0.30s
     Running `target/release/examples/redis_app`
568

It took our Rust app 568 milliseconds to connect to Redis, send 400k commands, and receive all their results.

$ crystal run --release bench/bench_redis.cr
00:00:00.328368151

Our Crystal app took just 328 milliseconds to run the same commands. That means the Rust app took 73% more time to perform the exact same work as the Crystal app.

The Caveat

The hard part about benchmarking anything that connects to a server is that the server may actually be your bottleneck. With databases especially, it's easy to get stuck waiting on I/O. In our example apps, the Redis server was indeed capping out at 100% CPU but neither app was, which is why we stop at 400k commands — going beyond that wasn't actually providing any useful information.

So how can we find just the time our app spent in the CPU and ignore all the time we spent waiting on the server? Turns out the UNIX time command tells us exactly this. Instead of cargo run and crystal run, we'll compile our programs and run them directly through time:

$ cargo build --release --example redis_app
    Finished release [optimized] target(s) in 0.26s
$ time target/release/examples/redis_app
563
target/release/examples/redis_app  0.28s user 0.04s system 48% cpu 0.656 total

Our Rust app used the CPU for 320ms (280ms in userland and 40ms in system calls).

$ crystal build --release bench/bench_redis.cr -o bin/bench_redis
$ time bin/bench_redis
00:00:00.327064055
bin/bench_redis  0.12s user 0.02s system 41% cpu 0.341 total

Our Crystal app used the CPU for 140ms (120ms in userland and 20ms in system calls). That means our Crystal app was 2.29x as fast on the CPU!

Also, it was interesting seeing both of these programs were waiting on Redis for over half of their runtime! As someone that has worked mostly in Ruby for 16 years, being able to saturate a Redis server with a single client is hilarious to me.

The End

The purpose of this post was not to say that Rust is slow. Rust is very fast. The idea was to see if Rust was really the performance trailblazer we all thought it was and it turns out Crystal has just as good, if not way better, performance for cases like this.

One thing that strikes me is that you never hear people talk about using Rust and Go for how nice they are to read and write the way you hear people talk about Ruby. It's always about the performance. But somehow we don't hear people talking as much about Crystal for the same reasons. I wonder if it's because it resembles Ruby that people don't take it seriously. Rust and Go have curly braces everywhere, so they're fast, right? 😄

Anyway, if you use Ruby or Python for their expressiveness and Rust or Go for their performance, it might be worth writing a part of your app in Crystal to get both.

Reasons I've Been Rejected For Software Engineering Roles

Jamie Gaskins — Tue, 07 Jan 2020 18:37:52 +0000

I've been seeing a lot of discussions of tech interviews in my Twitter feed and a lot of it is around the idea that someone needs to be "more technical" (that's not a thing, by the way — technical expertise isn't linear) or that they need to be able to balance a binary search tree or whatever from memory when the job never requires it.

The typical interview process at tech companies is almost worse than useless, so I wanted to share some of the comically awful reasons I've been rejected by companies.

One company rejected me because they didn't think I would be able to jive at their scale. There are two weird things about this. The first is that they asked zero questions about my experience with scale during the interview.

The second is that this team only handled referrals — so really only putting people through their customer-acquisition funnel. Unless this company was somehow managing to gain tens of thousands of new customers per second, it's unlikely that scale was actually a factor. That's the entire population of the US in a matter of hours, though, so probably not. Even if they were going with their company's total size, I've worked at companies several times their size with several times more traffic, data, and engineers.

Scale is an ego point for some developers. It's some "get on my level" shit.

But it's the kind of vanity metric that actively discourages optimizations and encourages poor scaling practices, so it requires a lot of discussion to understand someone's familiarity with it.

Another company rejected me because they didn't think I would enjoy working at a large company. I can't even begin to understand how they came to this as a hiring decision. Why would I apply if company size was a dealbreaker? Why are they trying to decide what I'd like? 😂

Another company rejected me because I struggled to find a given bug in the sass Ruby gem during "the debugging portion" of their technical interview — this was an on-site interview that lasted all day.

Apart from the fact that this Ruby gem contains 13k lines of code (not counting whitespace and comments), it's a parser and working with parsers isn't like working with typical apps. And in Ruby, parsers make heavy use of metaprogramming, making it that much more difficult to find a bug when you're unfamiliar with the code because you can't grep for what you need.

I asked the interviewer if the role required implementing parsers in Ruby, he said "probably not". So it was a pointless exercise, but they actually told me that my inability to locate and fix this bug in a 13k-LoC gem in 45 minutes was their reason for rejecting me.

During another interview, the interviewer asked very vague questions. Every time I asked for clarification on even the kind of response he was looking for, he just dumbed down the question. And he did it in a way that let me know I was losing points for getting "hints".

He did the same when I stopped asking him to clarify and started guessing at what he wanted. Then later, he asked questions I gave him answers for earlier when I was trying to guess at what he meant.

I remember standing in front of that whiteboard thinking "they're 100% gonna reject me because this guy can't ask the questions he wants the answers for". I mean, at least I saw the rejection coming.

Even so, this one was probably the hardest rejection because the engineering manager was excited about me and even introduced me to her team because she expected a positive outcome.

At another company, they asked me about my own strengths and weaknesses. This is a pretty pointless question in general but the rejection letter said "we're looking for engineers with a different set of strengths".

This particular interview was a shit show from start to finish, but this was my favorite bit.

None of these are small startups run by no-name techbros, either. These are well respected companies. If you're in the tech industry, you've probably heard of most of them, if not every single one of them, and you've almost definitely used some of their products and services.

And yet, no matter how good they are at providing snacks in their "kick-ass office in downtown San Francisco" or "unleashing the world's creative energy by designing a more enlightened way of working", somehow they're all shit at interviewing.

Sometimes interviewers will find arbitrary reasons to reject you that have nothing to do with you. Maybe the interviewer doesn't communicate well. Maybe they have a superiority complex and are rejecting you just to exercise that power. Maybe they just had a bad day.

For these interviews, there may actually be no way to pass it. You could probably do everything "right" and the interviewer would still find some excuse to shut you down. And a lot of the time, the team may actually be amazing but the interviewer is someone that works on a completely unrelated team who would never see you, anyway.

I've been working in this industry for 15 years. Interviewing is still every bit as terrible now as it was when I started. We're all being judged on the wrong criteria. Even when we get the job, it may not be for the right reason.

Enabling Crystal’s New Multicore Support

Jamie Gaskins — Wed, 25 Sep 2019 04:19:31 +0000

Crystal is a statically typed, object-oriented programming language with syntax heavily inspired by Ruby and concepts inspired by quite a few languages, including Ruby, Go, Rust, Swift, and more.

Concurrency

One of the nice things about Crystal is its concurrency model. Rather than managing threads, you spin up fibers using the spawn method:

spawn do
  puts "This runs when the program’s main fiber is sleeping or waiting on I/O"
end

This is powerful. Threads require a lot of hands-on management — if you create them, you have to collect them yourself — but fibers are managed by the garbage collector, so you can fire and forget if you like.

Fibers are also significantly lighter weight. You can use them to spin off background work so you can do things like send off 50 web requests concurrently rather than one at a time. You could do this with threads, but pthread_create and pthread_join (the libc functions that usually back threads) are expensive system calls, so you really shouldn't.

Concurrency != Parallelism

The downside of fibers has historically been that all Crystal fibers execute on the main thread. This lets you do a lot of I/O-bound work (HTTP requests, database queries, reading files from disk, etc), however CPU-bound work (serializing/deserializing JSON, crunching numbers for reports, etc) was limited to a single CPU core. Ruby, Python, and JavaScript all have this same limitation.

Yesterday, however, the Crystal team released version 0.31.0, which comes with multicore support! This allows us to do not only concurrent work like we had before, but also true parallel work — we can split our workload across as many CPU cores as our machine has. For example, here is a single Crystal process saturating a 32-core DigitalOcean droplet:

The code for this app was simply:

32.times { spawn { loop {} } }
sleep # Keep the main thread from exiting

Enabling Parallelism

Crystal's multicore support is still in preview, so it's off by default. You can enable it with the -D preview_mt compiler flag:

crystal build -Dpreview_mt my_app.cr

Or you can run it directly without creating build artifacts:

crystal run -Dpreview_mt my_app.cr

The best part, in my opinion, is that the level of parallelism (the number of fibers that can execute in parallel) is set up during app bootstrapping before your own application code actually runs by setting the CRYSTAL_WORKERS environment variable. This means you can tune the amount of CPU resources your app will try to use — and you can do it when the app starts rather than during the build process. So if you're running two different Crystal apps on the same 16-core server, they won't both be trying to use all 16 cores. You can assign 4 cores to one of them and 12 to the other:

CRYSTAL_WORKERS=4 first_app
CRYSTAL_WORKERS=12 second_app

How Does It Work?

Parallelism is configured while your app is bootstrapping — that is, wiring up all the parts it needs before it can begin executing your application code. That parallelism is achieved through a static thread pool. No threads are spun up or down while your app is running, all the threads are created by the time your first line of application code executes!

Each thread in this pool comes with its own fiber scheduler. It's basically doing what it does in single-thread mode, just across more threads. This means that a fiber currently runs only within the thread it's initially assigned to. This isn't necessarily the thread that created it, though. For example, if Thread 1 calls spawn, that new fiber may be assigned to Thread 4 and it will live on Thread 4 until it dies.

The Crystal team have discussed implementing "fiber stealing" (basically, if Thread 1 has nothing to do and Thread 2 has a lot of fibers, Thread 1 might take some of those fibers to spread around the work), but I have a feeling that's a ways off.

What Can I Do With This?

Anything that can benefit from concurrent work will automatically be parallelized. For example, web apps often use HTTP::Server from the Crystal standard library — either directly or through a framework such as Amber or Lucky. This class spins off every request handler in its own fiber. With the preview_mt flag enabled, this now spreads across CPU cores!

Background jobs like Sidekiq (yes, Sidekiq has been ported to Crystal by its author) perform each job in its own fiber. You can use the RabbitMQ client and spawn a fiber for each incoming message.

Or you can even split up work that you might otherwise do in parallel. Let's say you have the following code that iterates over an array and processes each one serially:

results = array.map { |value| process(value) }

This code is very simple, but if it takes a long time to process, it might be worth splitting individual parts across all of your CPU cores. To achieve this this, we can convert it into a producer/consumer setup where the producer spins up a fiber in which results are computed and passed through a Channel for the consumer to receive:

channel = Channel(MyValue).new(array.size)

array.each do |value|
  spawn { channel.send process(value) }
end

results = Array.new(array.size) { channel.receive }

Queues are often the solution to a producer/consumer problem and we're using a Channel as that queue. They're built into the standard library (and also used within Crystal itself) so we can count on them being there without installing additional dependencies.

Caveats

Unfortunately, multithreading there may be some libraries that aren't threadsafe yet. That's okay, fixing these issues is frequently a matter of wrapping mutexes around state changes to make them atomic (like you might with a database transaction), so it's a fantastic opportunity to make a contribution to an open-source library.

If you're unsure how to make this work for your application, you can always come by the Crystal Gitter channel or post on the Crystal forums or subreddit. The community is very helpful and we're all excited about multicore support coming to the Crystal ecosystem, so feel free to ask any questions you may have!

Tricksy Little Postgres Query Planner

Jamie Gaskins — Thu, 19 Sep 2019 00:10:24 +0000

We've had this query at work that has been irritatingly slow for a while, about 5-10 seconds during the course of a pretty common HTTP request. So far, nobody's been able to speed it up much. We ran EXPLAIN ANALYZE on the query and it seemed okay.

If you've never looked at an EXPLAIN ANALYZE result, they look something like this:

                                                                                    QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=2.93..360.99 rows=50 width=1205) (actual time=42.779..42.779 rows=0 loops=1)
   ->  Hash Left Join  (cost=2.93..1879.13 rows=262 width=1205) (actual time=42.778..42.778 rows=0 loops=1)
         Hash Cond: (table1.id = table2.table1_id)
         Filter: (((table2.table3_id = 712581) AND table1.flag) OR ((table1.table4_id = 712581) AND table1.other_flag))
         Rows Removed by Filter: 24211
         ->  Seq Scan on table1  (cost=0.00..1784.11 rows=24211 width=1205) (actual time=0.023..17.043 rows=24211 loops=1)
         ->  Hash  (cost=1.86..1.86 rows=86 width=8) (actual time=0.066..0.066 rows=86 loops=1)
               Buckets: 1024  Batches: 1  Memory Usage: 12kB
               ->  Seq Scan on table2  (cost=0.00..1.86 rows=86 width=8) (actual time=0.012..0.029 rows=86 loops=1)
 Planning Time: 72.257 ms
 Execution Time: 43.034 ms

The important parts of this are things like Hash Left Join, Seq Scan, and Hash. Another common one you'll see is Index Scan. It roughly translates to this sort of time complexity:

Plan	Complexity
`Hash`	O(1)	Backed by an in-memory hash table
`Index Scan`	O(log n)	Backed by an on-disk binary tree
`Seq Scan`	O(n)	Just iterates over rows in the table like you would over elements of any list
`Nested Loop`	O(n * m)	Iterating over the rows of one set for each row of another

The query plan above is an actual query plan from our DB (tables and columns are scrubbed). It's using a Hash Left Join and a Hash, so it should be pretty fast! It's using a Seq Scan in there, too, but it's happening to a set that's already been filtered — this is actually pretty common.

So if this query was on such a fast plan, why was it so slow? Today I decided to run the EXPLAIN against our production database and realized why:

                                                                                   QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.29..907487.63 rows=50 width=1936) (actual time=54.223..8893.723 rows=1 loops=1)
   ->  Nested Loop Left Join  (cost=0.29..1161584.09 rows=64 width=1936) (actual time=54.221..8893.721 rows=1 loops=1)
         Filter: (((table2.table3_id = 712581) AND table1.flag) OR ((table1.table4_id = 712581) AND table1.other_flag))
         Rows Removed by Filter: 2095442
         ->  Seq Scan on table1  (cost=0.00..477337.61 rows=2098223 width=1936) (actual time=0.021..4430.654 rows=2095443 loops=1)
               Filter: (flag OR ((table4_id = 712581) AND other_flag))
               Rows Removed by Filter: 392143
         ->  Index Scan using index_1 on table3  (cost=0.29..0.31 rows=1 width=8) (actual time=0.001..0.001 rows=0 loops=2095443)
               Index Cond: (table1.id = table1_id)
 Planning time: 4.166 ms
 Execution time: 8893.867 ms

It's using very different data structures. Not a single Hash in sight. Our LEFT JOIN, instead of backed by a Hash, is now running as a Nested Loop. That's rough.

It's most likely not joining using the Hash method anymore because an in-memory hash for tables with millions of rows in them is probably infeasible to run for a single query. Not because it can't do it for a single query, but rather that it can't do it for all queries concurrently.

With that in mind, it makes sense why it's using a slower query plan. It just didn't occur to us at the time that it would use a different one.

This is why, whenever you want to understand the performance of a query, you need to do it on your production database. Your development or staging data set will not give you the insight you need.

This is not always tenable since some companies may have very strict policies on who can access the production database, but it's important to have tooling around this to allow profiling of queries against real-world data.

How we fixed it

You're probably curious about our solution. What we landed on (after a few iterations) involved removing the LEFT JOIN altogether because we couldn't get it to run as anything but Nested Loop, which was about 99% of the query runtime. Instead, because of how we were using OR, we opted to run a UNION query that looks something like this:

SELECT *
FROM table1
WHERE table1.table3_id = 123456
AND flag

UNION

SELECT table1.*
FROM table1
INNER JOIN table2 ON table1.id = table2.table1_id
WHERE table2.table3_id = 123456
AND other_flag

The actual query is slightly more involved because it's generated by an ORM but it's pretty equivalent to this. The query plan is almost identical, even.

The first part of the query is why we were doing the LEFT JOIN to begin with. Since related rows in the other table were only guaranteed if other_flag was set, we couldn't use INNER JOIN for the whole thing.

This brought our query time, which was anywhere from 7-10 seconds depending on database load, down to a pretty consistent 125µs, a reduction in query latency of 99.9982-99.99875%. I actually had to check to make sure we were even hitting the right database because that number didn't look anything like what I expected. But sure enough, this does exactly what we needed it to do and it lets Postgres use 4 indexes (previously it was only using 1) and probably makes really nice use of the query cache.

Not bad for a day's work!

FaaStRuby: Serverless Functions as a Service for Ruby and Crystal

Jamie Gaskins — Tue, 29 Jan 2019 15:01:25 +0000

The "serverless" movement in web development has picked up a lot of steam in recent months. AWS Lambda now supports 6 languages and late last year announced support for Ruby:

Alex Wood

@alexwwood

I’m excited to finally announce what I’ve been working on the last few months. Ruby support for AWS Lambda is officially here!

17:47 PM - 29 Nov 2018

They also support custom runtimes so you can run anything you like. I tried it out recently and got a Crystal function deployed, but it was difficult to say the least.

First, I had to run it through the Serverless framework. If you're unfamiliar with it (as I was), you have to run it on Linux. It also requires a whole lot of integration with AWS, including CloudFormation, IAM, and all kinds of other services on AWS. Because of this, their intro video instructs you to give it administrator privileges. When you're just starting out and you have nothing on your AWS account, this isn't such a big deal, but this is horrible advice for your a company account with existing infrastructure. Never give any tool you don't control all the keys to the kingdom.

In the end, partly because I refused to give it full admin privileges, it took me about 4 hours to deploy a single Crystal function to AWS Lambda — CloudFormation rollbacks take foreeeeeever when it doesn't succeed due to insufficient privileges and I couldn't find anything to point out exactly what privileges it needs. If you already use Lambda and Serverless or you have an Operations or Infrastructure team that understands these things, I'm sure this would go much more smoothly, but I didn't have that for this particular task. I was starting it from scratch.

Then I found FaaStRuby which just announced support for Crystal. Within 10 minutes I went from nothing to having a Crystal function available at an API endpoint.

Getting FaaStRuby up and running is pretty quick:

gem install faastruby
faastruby create-workspace your-workspace-name
faastruby new your-function-name --runtime crystal:0.27.0
- For Ruby functions, you can omit the --runtime flag since it's the default
cd your-function-name
Replace the code in the generated src/handler.cr with your own code
- You may want to write some real specs or delete the generated ones. The ones they generate will likely fail and FaaStRuby doesn't deploy unless specs pass — this is a good thing.
faastruby deploy-to your-workspace-name

That's all it takes to get going — no registration forms, no payment details to mess with, just install a Ruby gem, run some CLI commands, write a couple lines of code, and hit your function at https://api.tor1.faastruby.io/your-workspace-name/your-function-name. It's pretty slick!

It still seems to be an early-stage service, so it doesn't have all the nice things that AWS Lambda has, but if all you're trying to do is deploy a cloud function quickly in Ruby or Crystal, it'll do what you need without all the ceremony that comes with using AWS.

Procs vs Callables in Ruby

Jamie Gaskins — Wed, 05 Sep 2018 03:57:08 +0000

This article was originally posted on jgaskins.org.

I've been playing with RabbitMQ recently, comparing it to our current use of SNS+SQS as our message bus at work. One of the nice things about it is that, with the bunny gem, you subscribe to messages from a queue by passing a block telling what to do with that message:

queue.bind(exchange).subscribe do |delivery, metadata, message|
  do_things_with(message, metadata)
end

It started me down a rabbit hole of "how much performance does this need?" so I could figure out whether this should run in its own process. That's when I started looking too closely and checking out how we could maximize performance.

I wanted to understand the performance of the gem, especially since consumers of message queues should be fast and have minimal overhead, so I opened up the code and found that when that block is called, it's called with splat args, which then calls the block by splatting the same args.

NOTE: This is not a criticism of the bunny gem, splat args, or anything. This was simply an exploration of the performance characteristics of the pattern of taking a block and calling that block later, along with a few variations of that pattern. These are all common conventions in Ruby and I think it's useful to understand how well they perform.

The first thing I wondered was what the performance cost of calling procs was vs calling a PORO's call method — that is, a callable object.

Assumptions and Hypotheses

I had a feeling that procs would be slower. I didn't have anything on which to base that assumption, but Ruby implementations are very much optimized around the idea of sending messages to objects and procs aren't run-of-the-mill objects — they're basically a Ruby binding to some bytecode. I don't know how heavy those bindings are, but given that you can get all kinds of introspection out of them (including local variables), I assumed they'd be pretty heavy. So I'm assuming a lot here.

Something that was less of an assumption but more of a hypothesis was that splat-args would be slower than explicit arguments. Splat args have to allocate and populate an array, so there's a performance cost to them. Still, I wasn't completely certain of it, so it was at best a hypothesis.

Speculation about performance without benchmarks is a waste of time, so I wrote some, including calling both with splat args. Turns out my guesses were pretty close (click the link to see the benchmark code):

Comparison:
     callable no arg: 10095848.2 i/s
   callable with arg:  9777103.9 i/s - same-ish: difference falls within error
     callable 3 args:  9460308.0 i/s - same-ish: difference falls within error
callable splat args (0):  6773190.5 i/s - 1.49x  slower
         proc no arg:  6747397.4 i/s - 1.50x  slower
       proc with arg:  6663572.5 i/s - 1.52x  slower
         proc 3 args:  6454715.5 i/s - 1.56x  slower
callable splat args (1):  5099903.4 i/s - 1.98x  slower
 proc splat args (0):  5028088.6 i/s - 2.01x  slower
callable splat args (3):  4880320.0 i/s - 2.07x  slower
 proc splat args (1):  4091623.1 i/s - 2.47x  slower
 proc splat args (3):  4005997.8 i/s - 2.52x  slower

This was disappointing for 2 reasons:

Proving yourself correct teaches you very little; proving yourself wrong teaches you a lot. At best, I proved a bunch of mildly educated assumptions correct.
Capturing and later calling blocks is such a common practice in Ruby that I wonder how much performance we're losing as a result

On the bright side, I'd gone down enough rabbit holes to find this out. If I'd been wrong, I'd have gone down even more to understand why.

What Do?

It would be silly to say "never capture blocks because performance". Capturing blocks in Ruby might be a bit slower, but it's a powerfully expressive concept and it's unlikely that the difference in performance will make that much of an impact in your app — I was still getting 6.7 million calls per second with a proc. If you need to call a captured block on the order of millions of times per second, you'll probably benefit from this article. Otherwise, this is largely an academic exercise and that's okay, too.

If you want to optimize performance while still allowing block capture, you can do both by taking a callable or a block:

class ThingThatHasEvents
  def on event_name, handler=nil, &block
    @events[event_name] << (handler || block)
  end
end

You'll want to have a check in there to ensure you receive one or the other, but making affordances for passing either one will give you the expressive API of receiving a block while still accepting the faster path of callable objects. With a typical "event handler" style where the event is emitted with the call to each handler, we can see this goes up to 45% faster.

Unfortunately, the benchmark shows that a heterogenous set of event handlers (some passed as blocks, some passed as callable POROs) is actually slower than procs-only, but only by about 10% — much less than the difference between procs and callables separately.

Always Benchmark

I may have been right about this, but performance claims without benchmarks are always bullshit. Always benchmark.

Even if you've done something similar before.
Even if you've done the exact same thing before in a different app.
Even if you've done the exact same thing before in the same app on a different Ruby VM.

I'll likely put in a PR to the bunny gem to see if we can remove the splat-args and allow subscribing with a non-Proc PORO. In the meantime, the current implementation provides enough performance for our needs.

Fast Type-Checked Serializers for Ruby Web APIs

Jamie Gaskins — Sun, 11 Feb 2018 07:52:15 +0000

When you need two different processes to be able to talk to each other, they need to be able to connect and speak the same language. If one of them is a web app, you're using HTTP (and everything it's built on top of), so that covers most of it. If you're sending requests and receiving responses serialized as JSON, you're even closer. But we still need to figure out that last mile — what JSON objects are we going to send and receive?

If our web server is running on Ruby, we just need to get our models converted into hashes and collections converted into arrays. Conversion to JSON is a simple to_json call at that point. How we convert them into those hashes and arrays is the choice to be made.

Conversion Options

There are plenty of gems available to convert arbitrary Ruby objects into our JSON-serializable format. The most well-known of these is active_model_serializers, but a couple weeks ago Netflix announced their own serialization gem called fast_jsonapi.

With both gems, you declare your serializers like this:

class OrderSerializer < ActiveModel::Serializer
  attributes(
    :id,
    :customer_name,
    :customer_id,
    :line_item_ids,
    :delivery_address,
    :delivery_instructions,
    :total_price,
  )
end

The Downside of Those Options

Both of those gems are great. You can tell by looking at this serializer exactly what fields it'll be sending. The thing they're missing is validation of the types of the data they are emitting. Is delivery_address a string or is it broken out into a hash with each address part? Which of these fields can be nil? Is total_price sent as a string to be used presentationally, a floating-point number for calculation, or an integer number of cents to avoid floating-point error? These are impossible to tell by looking at the attribute declaration in the serializer.

You might be thinking "why do I want type checking in a dynamic language?!" While I can see the benefits of static typing, I really do enjoy the freedom that dynamic typing gives us to build applications. However, when you have two different applications that must both agree on how they speak to each other, you need to be 100% sure about all of the details, just like getting contract details ironed out in a consulting agreement. Adding unit tests to verify that a serializer emits the right data types is a lot of work. What if the serializers did that for us and would even let us know if our data was incorrect in production?

Well, I wouldn't be writing this if I didn't already have a solution for that. Enter primalize, a serialization gem that comes with type checking out of the box. Primalize is so named because it converts more advanced objects into their primitive counterparts, but it does it in an intelligent way.

How does it work?

Let's start by declaring a serializer:

class OrderSerializer < Primalize::Single
  attributes(
    id: string, # UUIDs for primary keys are great
    customer_name: string,
    customer_id: string,
    line_item_ids: array(string),
    delivery_address: primalize(AddressSerializer),
    delivery_instructions: optional(string),
    total_price: integer,
  )
end

Notice the attributes we declare all have types. We say the id is a string, the line_item_ids is an array containing string values. The total_price is an integer. These are pretty easy to understand and they tell us exactly what we're getting.

Notice the delivery_instructions attribute is marked as optional. This means it can be nil. If an attribute isn't marked as optional, it can't be nil.

Here's a list of the various types that Primalize supports for model serializers:

integer: whole numbers
float: floating-point numbers
number: any numeric value
string: text
boolean: explicitly true or false (not "truthy" or "falsy" values)
array(*types): an array containing values of the specified types
- Example: array(string, integer)
optional(*types): any of the specified types or nil
- Example: optional(string), both "foo" and nil are acceptable values
enum(*values): must be one of the specified values
- Example: enum('requested', 'shipped', 'delivered')
timestamp: a Date, Time, or DateTime value
any(*types): any value of the given types
- Example: any(string, integer) will only match on strings and integers
- If no types are specified, any value will match
primalize(YourPrimalizerClass): primalizes the specified attribute with the given Primalize::Single subclass
- Example: primalize(OrderSerializer)
object(**types): a hash of the specified structure
- Example: object(id: integer, name: string)
- Only the required keys need to be specified. The rest of the hash will pass.
- If no keys are specified, all of them are optional and it will match any hash.
- Ruby objects already define a method called hash that's used for resolving hash keys and determining Set inclusion, so we had to use the more language-agnostic name object. If we'd used hash, it would be effectively impossible to use a serializer class as a hash key or store it in a Set.

These type declarations are composable, so we can set up some really complex type declarations if our API calls for it:

attributes(
  user: object(
    name: optional(string),
    email: string,
    nicknames: array(string),
    role: optional(enum('user', 'agent', 'manager', 'admin')),
  ),
)

If you find yourself writing a lot of nested objects, though, it might be worth extracting that to another serializer and using primalize(ThatSerializer).

What happens if the type check fails?

In Ruby, we can't enforce that our models don't have the wrong types of attributes because any variable can hold any value, but we can run a type check at the time of serialization.

Serializers have a default type-mismatch handler, which is a callable object (as in, responds to call) that receives serializer_class, attribute, type, value. By default, it raises an exception, which is great for a development environment. In production, though, it might be preferable to let it pass through while still sending alerts.

You can customize what you do when a type mismatch occurs on your individual serializer class by setting MySerializerClass.type_mismatch_handler to your preferred method of handling it. To set it for all model serializers, use Primalize::Single.type_mismatch_handler. For example:

MySerializerClass.type_mismatch_handler = proc do |serializer, attr, type, value|
  message = "#{serializer}##{attr} is specified as #{type.inspect}, but is #{value.inspect}"

  Slack.notify '#bugs', message
  BugTracker.notify message

  # the return value of the block is the value to be used for that attribute
  value
end

Attribute conversion

If an attribute isn't already the type you're expecting, you can provide a block to its type declaration to specify how to coerce it to that type. For example, if an Address#city returns a City object instead of just the name, we could serialize it like this:

class AddressSerializer < Primalize::Single
  attributes(
    city: string { |city| city.name },
    # ...
  )
end

This indicates that we would call name on the city that's in the address's city attribute. The type check will still occur here. If the result of that block isn't a string, we'll trigger a type mismatch.

Virtual attributes

Sometimes you want to provide attributes that don't actually exist on the model being serialized. Just like how our server-side domain models don't need to match the database schema, a client doesn't need to know that the server-side model doesn't have a particular attribute. For those "virtual" attributes, you can define a method that will compute the attribute from what the model does have:

class AddressSerializer < Primalize::Single
  attributes(
    latitude: float,
    longitude: float,
    # ...
  )

  def latitude
    object.coordinates.latitude
  end

  def longitude
    object.coordinates.longitude
  end
end

Composite Serializers

That's just individual model serializers. There's also first-class support for returning associated objects in a single response without nesting them with primalize(AnotherSerializer):

class OrderResponse < Primalize::Many
  attributes(
    order: OrderSerializer,
    line_items: enumerable(LineItemSerializer),
    address: AddressSerializer,
    customer: CustomerSerializer,

    # Only required for corporate accounts
    purchase_order: optional(PurchaseOrderSerializer),
  )
end

I typically refer to these as "response serializers" and, while it's possible to serialize just the domain model in an API response, I almost always wrap them inside a serializer like this in case I need to return associated models in the future. If you have any API consumers you don't control, once you start returning the model as the top-level object, you're stuck with it most of the time.

To use this serializer, you instantiate it with the keys you gave it:

OrderResponse.new(
  order: order,
  line_items: order.line_items,
  address: order.delivery_address,
  customer: order.customer,
  purchase_order: order.purchase_order,
)

Primalize::Many doesn't traverse the object graph for you, and this might feel inconvenient, but it's intended functionality. It ensures that you can customize what you're sending. For example, if your order is an ActiveRecord model, you may not want to send all of its line_items together. You might split them between taxable_line_items and non_taxable_line_items for some business reason. If the serializer traversed the association for you, you might not be able to specify that without adding a method on the Order model. With Primalize, though, you can set up your serializer like this:

class OrderResponse < Primalize::Many
  attributes(
    # ...
    taxable_line_items: enumerable(LineItemSerializer),
    non_taxable_line_items: enumerable(LineItemSerializer),
  )
end

OrderResponse.new(
  # ...
  taxable_line_items: order.line_items.taxable,
  non_taxable_line_items: order.line_items.non_taxable,
)

The type checking comes into play with response serializers, as well. For example, if we passed a single line item in where we specified enumerable(LineItemSerializer), we would get an error. If we passed nil for a field without specifying it as optional, we would also get an error.

All this helps make more robust API endpoints.

JSONAPI

Some client applications might be written in a way that is more suited to the JSONAPI response structure. For such applications, there is a JSONAPI wrapper for Primalize.

Performance

I mentioned in the title that these serializers are fast, but I haven't touched on that part yet. When I benchmarked Primalize::JSONAPI against AMS and Netflix's fast_jsonapi gem, it was over 1200% as fast as AMS and about half as fast as the Netflix gem. When you consider that the selling point of fast_jsonapi is that … well … it's fast, and the difference between it and Primalize to serialize over 1000 models is 12ms (less than 12µs each), it's still close enough. On typical payloads (dozens of models, maybe 100), you'll have garbage-collection pauses longer than the difference between them.

Also, that benchmark was using the JSONAPI wrapper, which is doing considerably more work (including its own naive traversal of associated models). If you don't require that particular format, you can stick with Primalize::Many to cut off about 25% of that time.

I don't know about you, but I'm certainly willing to trade 12ms (much less on typical payloads) for peace of mind that my response payloads match what the client expects.

Future Development

Primalize is a gem based on a pattern I implemented at a previous employer. It has been used in production for around two years and has stabilized the communication between their API and its consumers significantly while also improving its performance. With that said, there are still ways to improve.

One idea that a coworker at that employer requested was the ability to generate RAML or Swagger documentation. For example, if an API endpoint returns an OrderResponse, you should be able to generate the exact structure a client could expect for that endpoint. RAML docs can be imported into Postman for easier testing and consumption of REST APIs.

Performance could probably be improved even more, both in the baseline Primalize classes and the JSONAPI wrapper.

If you'd like to contribute, I'm always open to conversation (gitter / twitter / comments on this post), suggestions, and pull requests. Thanks, everyone! ❤️