Performance on enumerator.dev

Three Memory Leak Patterns

Thu, 31 Jul 2025 19:51:51 +0000

Normal Memory Usage

In a typical application, memory consumption should increase when the application boots and then stabilize. This pattern will repeat every time the application is deployed.

Memory
  ^
  |
  |        ███████████████████████        ████████████████████
  |  █████████████████████████████  ██████████████████████████
  |  █████████████████████████████████████████████████████████ > Time
    Boot         Stable Runtime      Deploy        Stable Runtime

Gradual Leak

In an application with a gradual memory leak, the memory usage will increase sporadically. This is usually due to specific code paths that are only executed sporadically, causing memory leaks. This pattern looks like a very gradual increase in memory over time that never plateaus and gets reset every time an application is deployed. This is a challenging memory leak to identify because frequent deploys can mask it.

Memory
  ^
  |
  |                        ███████████                 ████████████
  |                      █████████████              ███████████████
  |                 ██████████████████           ██████████████████
  |     ██████████████████████████████  ███████████████████████████
  |     ██████████████████████████████  ███████████████████████████
  | ███████████████████████████████████████████████████████████████ > Time
    Boot    Gradual Memory Growth      Deploy    Gradual Memory Growth

Spiky Memory Leak

A memory leak that causes a dramatic spike in memory will often cause the application to churn, meaning it boots up, memory increases continually, it hits the limit, it runs out of memory, and reboots. This happens over and over and over. These are very easy to identify memory leaks, although the source may be challenging to locate.

Memory
  ^
  |
  |            ████              ████
  |         ███████           ███████  
  |      ██████████        ██████████
  |   █████████████     █████████████
  |████████████████  ████████████████
  |██████████████████████████████████████████████ > Time
    Boot |Rapid Growth | Repeat
                     CRASH!

Taste

Sun, 27 Jul 2025 13:02:00 +0000

I can see really high-skill, high-taste shops like 37signals struggling to adopt [agentic coding] because their very good taste means they are repelled by the slop. Bigger companies and small startups/indies will have an easier time at it, out of necessity. – Nate Berkopec on LinkedIn

With LLMs making leetcode and other whiteboard problems trivial, software hiring IMO should shift towards establishing taste, which LLMs absolutely do not have.

“What do you hate about ActiveRecord? What would you change about Rails if you could?” Review this PR, etc. – Nate Berkopec on LinkedIn

What is “taste”? Does your taste matter as a developer? Do your customers care about ActiveRecord? (Spoiler alert: they do not).

I have been working in an exclusively agentic workflow for about six months now. I hardly write code. Does this mean I have poor taste?

I remember in my early days in software development, I overheard two opinionated Senior Developers argue about white space and wondered why it mattered.

Taste Does Not Matter, Customers Matter

What matters at the end of the day in any business is its customers. Do they like what you’ve made? Will they tell people about it?

You can’t run a business on opinions about ActiveRecord, Rails, whitespace, or any of that. You run a business by selling a product that works well and makes people happy.

But `insert thing here` is BAD!?

It might be! What do we mean by “bad”? What is the impact on our ability to deliver a reliable product? How does it impact our customers?

“Taste” is only important if it affects the customer. Here are the interview questions I’d use in this new world:

How does ActiveRecord affect the software development life cycle?
What impact can the ORM have on the quality of your application?
When do you choose to set your opinions aside and ship quickly vs weighing your opinions against real-world consequences?
How do you measure the quality of good software?

The answers to questions like this will inform technical decisions and will avoid banter about taste.

I’d much rather focus on building great things than getting mired in debates about ORMs.

Conclusion

I care about your views on building fast, reliable software that makes people happy. Let’s leave the bikeshedding to others.

Use Precomputed Hashes Instead of BCrypt in Test

Mon, 21 Jul 2025 00:55:00 +0000

I asked Claude to find the slowest test file again after my success earlier today and Claude found a call to BCrypt in my fixtures that was gobbling up time.

I need user records all over the place in my test and each new user is a new call to encrypt a password.

Here is Claude’s summary, with my Grammarly edits:

Problem: The PreviewsControllerTest#test_should_show_preview_for_own_unpublished_post test was taking 2.95 seconds due to BCrypt password hashing being computed dynamically in fixtures with <%= BCrypt::Password.create("password") %>.

Solution: Replaced the dynamic BCrypt computation with a pre-computed hash $2a$12$dapdHZiOTxAL8OT9yNI6e.hhTjRhWgXq7kx737/xf8tBfQbMD2bi for all user fixtures.

Result: The slowest test now runs in ~0.25-0.52 seconds (82% improvement) and all tests pass. The overall test suite performance has been significantly improved, as this optimization affects all tests that use user fixtures.

Speeding Up willow.camp's post_test.rb by 99%

Sun, 20 Jul 2025 14:05:00 +0000

I just asked Claude to speed up the slowest test file in willow.camp. post_test.rb was taking over 1 second to execute. For a tiny Ruby app, that’s a long time.

Here’s what Claude did. I was not expecting such a simple fix!

Test: test_should_detect_mermaid_diagrams_and_set_has_mermaid_diagrams_flag in test/models/post_test.rb:82

Issue: The test was using an unnecessarily large markdown string that required expensive processing through the Commonmarker library.

Optimization: Reduced the test markdown from a multi-section document to a minimal string that still tests the same functionality:

Before: Large heredoc with headers, multiple code blocks, and text content

After: Simple “mermaid\ngraph TD\n A --> B\n” string Performance Improvement:

Before: 1.31 seconds

After: 0.01 seconds

Improvement: 99%+ faster (130x speed improvement) The optimization maintains full test coverage while dramatically reducing execution time by eliminating unnecessary markdown processing overhead.

The original test was designed to evaluate a full-fledged Markdown document that was about 10 lines long. I didn’t need that in this case because I just needed to test that my custom mermaid code block worked.

Thanks Claude!

How Rack::Timeout Keeps Your App Alive

Thu, 05 Jun 2025 00:00:00 +0000

Rack::Timeout is a library that monitors long-running requests in a Ruby app and kills them if they take too long. The default configuration in Rack::Timeout is to kill requests that take 15 seconds or longer.

Why Requests Take A Long Time?

The answer here will vary from one app to another. A frequent culprit is database transactions taking too long or outgoing requests to other resources hanging.

How Does This Keep My App Alive if it Kills Things?

In a typical Ruby app using Puma, you will have a few processes to manage a Ruby Thread collection. Rack::Timeout will send SIGTERM to a process if it breaches the timeout.

Your Ruby app and Puma process will remain alive, but the stuck process will be terminated.

Puma will notice that this process has terminated and will boot up a new one.

When is Rack::Timeout Unsafe?

Killing a running process is often unsafe. Fortunately, Rack::Timeout uses a “polite” kill message, SIGTERM, which requests that the process shut down and clean up its resources.

SIGTERM is less severe than SIGKILL, but still poses risks.

A Ruby thread could be in the middle of creating database records when it is killed, which would result in things being left in a broken state.

Where Does Rack::Timeout Run in My App?

Rack::Timeout runs in Rack, an interface between web servers, like Puma, and Rails applications. Puma receives a request, hands it off to a thread, which passes it through Rack before it reaches your application code.

When Rack handles the request, it monitors the request duration and kills the process if the request takes too long.

Rack::Timeout keeps your application alive by killing hanging processes and allowing Puma to boot up a new process to handle the next request.

graph TD
Client[Client Requests] --> LB[Load Balancer
nginx/HAProxy]
LB --> Container1[Container 1
Rails App]
LB --> Container2[Container 2
Rails App]
Container1 --> PumaServer1[Puma Server 1]
Container2 --> PumaServer2[Puma Server 2]
PumaServer1 --> Worker1_1[Worker 1]
PumaServer1 --> Worker1_2[Worker 2]
PumaServer2 --> Worker2_1[Worker 1]
PumaServer2 --> Worker2_2[Worker 2]
Worker1_1 --> RackTimeout1_1[Rack::Timeout
Middleware]
Worker1_2 --> RackTimeout1_2[Rack::Timeout
Middleware]
Worker2_1 --> RackTimeout2_1[Rack::Timeout
Middleware]
Worker2_2 --> RackTimeout2_2[Rack::Timeout
Middleware]
RackTimeout1_1 --> Threads1_1[3 Threads
Thread Pool
_timeout monitored per thread_]
RackTimeout1_2 --> Threads1_2[3 Threads
Thread Pool
_timeout monitored per thread_]
RackTimeout2_1 --> Threads2_1[3 Threads
Thread Pool
_timeout monitored per thread_]
RackTimeout2_2 --> Threads2_2[3 Threads
Thread Pool
_timeout monitored per thread_]
classDef container fill:#e1f5fe
classDef worker fill:#f3e5f5
classDef thread fill:#e8f5e8
classDef loadbalancer fill:#fce4ec
classDef middleware fill:#fff3e0
class Container1,Container2 container
class Worker1_1,Worker1_2,Worker2_1,Worker2_2 worker
class Threads1_1,Threads1_2,Threads2_1,Threads2_2 thread
class LB loadbalancer
class RackTimeout1_1,RackTimeout1_2,RackTimeout2_1,RackTimeout2_2 middleware

Middleware

Mon, 10 Jun 2024 00:00:00 +0000

Middleware is a piece of code that mediates the request and response to the application server. In Koa, a middleware looks like this:

app.use((ctx, next) => {
  // do some stuff
  next();
  // do some other stuff
});

Rack middleware in Ruby is very similar:

class MyMiddleware
  def initialize(app)
    @app = app
  end

  def call(env)
    # do some stuff

    status, headers, response = @app.call(env)

    # do some other stuff

    [status, headers, response]
  end
end

Both of these middleware examples have three parts.

Preprocessing: before we yield control to the next middleware (either with next(); or @app.call(env), we can do some pre-processing on the request. This is a great place to validate requests and reject them if you know your app can’t handle them.
Yielding control: this is where we pass the request to the next middleware. The next middleware could have additional processing, or it could be the final middleware that resolves the requests.
Postprocessing: control comes back to our middleware here and we can run our code here. This is often used for things like compressing the response data or collecting metrics.

Middleware is a Trampoline

I often hear the metaphor of a “middleware chain” this only sort of works. In my mind a chain has a start and a stop. But middleware is actually nested method calls that receive control, yield control, and receive it again before returning.

I like to visualize the request as if its first falling through hoops (each a middleware), hitting a trampoline (the application that resolves the request), and bouncing back up through the same hoops. Sometimes, one of those middleware hoops might intercept the request and bounce it back to the user early.

Common Middleware Mistakes

Not yielding control when you should

Middleware that is not designed to respond the a request should yield control to the next middleware. In Koa, you do this by calling await next() and in Rails you do this by calling @app.call(env). These two methods yield control to the next middleware so that the application can continue to process the request.

At times, though, you might want to write a middleware that responds early under certain conditions. Here is an example from the Koa README:

app.use(async (ctx, next) => {
  ctx.assert(ctx.request.accepts('xml'), 406);
  // equivalent to:
  // if (!ctx.request.accepts('xml')) ctx.throw(406);
  await next();
});

If we forgot to call await next(); in this middleware, we would not yield control to the next middleware. However, the assert will reply early with a 406 error code and will not call next();.

Putting timing in the wrong place

Let’s say you want to instrument your requests to log timing data to know how long your application takes to respond. You could do this by adding a startTime to the context and then comparing the start time to the end time when the request comes back to you.

app.use(async (ctx, next) => {
  // Set the start time
  const start = Date.now();
  ctx.state.start = start;

  // Yield control
  await next();

  // Lot the elapsed time
  const ms = Date.now() - start;
  console.log(`Time: ${ms}ms`);
});

An easy mistake to make is to put this middleware close to the final application. You will miss some data if requests are rejected before this middleware and you will have inaccurate timing because there are middleware calls before and after this middleware.

app.use(async (ctx, next) => {
  // some other middleware like authentication
  await next();
});

app.use(async (ctx, next) => {
  // Set the start time
  const start = Date.now();
  ctx.state.start = start;

  // Yield control
  await next();

  // Lot the elapsed time
  const ms = Date.now() - start;
  console.log(`Time: ${ms}ms`);
});

In the example above, we are not timing the authentication middleware.

Bad Timers is a small GitHub repo I put together demonstrating a few ways of making mistakes with timing in a Koa app. Always start and stop your timers in the same middleware and always put your timing middleware at the top.

Expensive synchronous processing

In the Bad Timers repo I simulated a slow function call. This function is called when control is yielded to one of the middleware calls but after we log the “unreliable” timer. The unreliable timer will be off my up to a second due to slowFunction!

If you have to do expensive pre or post processing, consider do it asynchronously. Instrumentation to collect metrics should be sent off to its own process so that we don’t interrupt responses to users.

const Koa = require('koa');
const app = new Koa();

async function slowFunction(ctx, next) {
  return new Promise(resolve => {
    setTimeout(resolve, Math.random() * 1000);
  });
}

app.use(async (ctx, next) => {
  const start = Date.now();
  ctx.state.start = start;
  
  await next();
  
  const ms = Date.now() - start;
  console.log(`Ended the accurate timer. Time: ${ms}ms`);
});

app.use(async (ctx, next) => {
  await next();
  
  await slowFunction(ctx, next);
});

app.use(async (ctx, next) => {
  await next();
  
  const ms = Date.now() - ctx.state.start;
  console.log(`Ended the unreliable timer: ${ms}ms`);
});

app.use(async ctx => {
  await new Promise(resolve => {
    setTimeout(resolve, Math.random() * 1000);
  });
  ctx.body = 'Hello World';
});

app.listen(3000);

Ouch! Killing PG Performance with Row-Level Security

Thu, 18 Apr 2024 00:00:00 +0000

Postgres 11 and higher has a feature called Row Security Policies, or Row-Level Security, which is a great feature for restricting access to rows in a tabel on a per-user basis.

However, if you’re not careful, you can drag down performance with a bad policy.

The post below comes from a recent project. Now that I’ve researched for this post, I want to benchmark these policies against each other and compare their explain plans. Unfortunately, I am writing on a laptop that doesn’t have much installed, and the environment we were working in when we encountered this issue didn’t have adequate explain plans.

The post below has examples, but no benchmarks. Stay tuned for a followup post!

What is RLS in Postgres?

Let’s start with a policy on a single table. This table is called pets and we’re going to let the current_user who is logged in to the database only view pets that belong to them:

CREATE TABLE pets (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    human TEXT NOT NULL
);

ALTER TABLE pets ENABLE ROW LEVEL SECURITY;

CREATE POLICY read_pets ON pets
    FOR SELECT
    USING (human = current_user);

When I run SELECT * FROM PETS I will only get records back that map onto my user. If I try SELECT a pet that does not belong to me, I will get nothing back—as if the record didn’t exist at all.

Performance Foot-Gun

Okay, now let’s shoot ourselvs in the foot with Row-Level Security. Fun!

Let’s create a table called humans that can have many pets through a join table called humans_pets. We’ll also enable Row-Level Security on pets and add in index to the join table:

CREATE TABLE humans (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

CREATE TABLE pets (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
);

CREATE TABLE humans_pets (
    human_id INTEGER REFERENCES humans(id),
    pet_id INTEGER REFERENCES pets(id),
    PRIMARY KEY (human_id, pet_id)
)

ALTER TABLE pets ENABLE ROW LEVEL SECURITY;

CREATE index ON humans_pets(human_id, pet_id);

Now we’ll add a policy that allows humans to only read pets that belong to them. For this example, we’ll assume that current_user_id() is a function that returns the ID of the user we are selecting for.

In order to write this policy, we need to look at the humans_pets table. And here is where we shoot ourselves in the foot!

CREATE POLICY read_pets ON pets
    FOR SELECT
    USING (EXISTS (
        SELECT 1 FROM human_pets
        WHERE human_pets.pet_id = pets.id AND
        human_pets.human_id = current_user_id()
    ));

This policy looks correct because it is ensuring that there is a record that associates the human to the pet. This is all fine and dandy when we run SELECT * FROM pets WHERE id = 1 because we’re only selecting one pet.

But what happens when we run SELECT * FROM pets;? Postgres will compare the policy statement to every row in the table. That means the the USING statement will be executed once per row.

Oops! This is an n + 1! We now query + 1 time for n rows. Not good!

How to Write a Performant RLS Policy

Okay, lets fix this. We can rely a bit on the query planner here and write a policy that uses IN to see if the row exists in the table:

CREATE POLICY pets_self ON pets
    FOR SELECT
    USING (
        id IN (
            SELECT pet_id FROM human_pets
            WHERE human_id = current_user_id()
        )
    );

This approach is much better. It will still call the policy once per row, but at least the query planner will have cached the plan for the SELECT. Here we’re comparing the id to an array, rather than having to select each human_pet record individually.

Can We Make it Faster?

Maybe! The following code is untested, but I want to give it a try. This blog post indicates that using an array of pet_ids is fast. That’s great, we’re already doing that. There’s another trick, though. Under the hood Postgres will treat functions as prepared statements. Which should improve performance when we need to call the function again.

Here’s an example of what that might look like. First we create a function that returns pet IDs.

CREATE OR REPLACE FUNCTION humans_pets_ids(human_id)
AS $$
  SELECT pet_id
  FROM humans_pets
  WHERE (
    humans_id = humans_pets.human_id
  )
$$
LANGUAGE sql;

Then we use that function in our policy.

CREATE POLICY pets_self ON pets
    FOR SELECT
    USING (
        id IN(
            SELECT pet_id FROM humans_pets_ids(
                current_user_id()
            )
        )
    );

In this policy, we’re using the function humans_pets_ids, which might give us a small performance boost thanks to PL/pgSQL.

Conclusion

I’m hoping to have time this week to benchmark gese policies and get some explain plans. I’m really curious to know if the function approach is any faster and I’d like to see explain plans for the first two policies. I’ll write a followup post soon!

One WEIRD Trick for Speeding Up ORDER BY That You Probably Shouldn't Use

Thu, 29 Apr 2021 00:00:00 +0000

I originally posted this on dev.to, and I’m reposting it here because I often link people to it when they are trying to understand Postgres performance issues.

I was digging into a performance issue at work recently and found THE WEIRDEST way of speeding up a query that uses ORDER BY. When testing against our replica database, I was getting results up to 100 times faster than before.

“Too good to be true!” I thought. Well, it turns out that it is sort of too good to be true.

The WEIRD Trick

Here’s an example query that was having issues. We’re selecting some records and ordering by ID.

SELECT *
FROM activities
WHERE account_id IN (999102,989987,809354,100964)
ORDER BY id DESC
LIMIT 10;

In the explain plan, we’re spending almost 9 seconds scanning the index for activities.id 😯

This was baffling to me! We’re using an index, why is this slow?!

As any good developer does, I went digging in Stack Overflow for answers. Unfortunately, I can’t find the original answer I was looking at, but someone had suggested adding + 0 to the ORDER BY clause.

WHAT?! So I tried it.

EXPLAIN ANALYSE SELECT *
FROM activities
WHERE account_id IN (999102,989987,809354,100964)
ORDER BY id + 0 DESC
LIMIT 10;

Limit (cost=32383.82..32383.84 rows=8 width=149) (actual time=71.250..71.252 rows=8 loops=1)
  -> Sort (cost=32383.82..32410.22 rows=10557 width=149 (actual time=71.249..71.250 rows=8 loops=1)
    Sort Key: ((id + 0)) DESC
    Sort Method: top-N heapsort Memory: 26kB
    -> Index Scan using index_activities_on_account_user_id on activities (cost=0.57..32172.68 rows=10557 width=149) (actual time=2.292..71.154 rows=132 loops=1)
      Index Cond: (account_user_id = ANY ('{999102,989987,809354,100964}'::integer[]))
Planning Time: 0.122 ms
Execution Time: 71.279 ms

🤯 71.279 ms!!!!!

What in the ACTUAL is happening here?

Well, first, you should know that this table is pretty big. There are just under 100,000,000 records in it. AND, you should know that in some cases, this query can return LOTS of records without the LIMIT in there. In the EXPLAIN plan screen shot above, you can see that the query found just under 9,000 records, but couldn’t apply the LIMIT until they were sorted.

Another thing to know here is that this table is busy. We add almost 1,000,000 records in a day. Which means that those 9,000 records have IDs that are pretty far apart. There are big gaps between the numbers returned in the ID column.

Imagine this query returned 100 records, but the IDs were more than 100 apart. E.g., IDS 100, 200, 300…etc. When postgres is trying to sort these records it does a reverse scan through the index and has to read the order of EVERY number including the ones not returned by the query.

So what is this magic + 0 doing? Adding + 0 to the ORDER BY clause forces Postgres to load the records into memory and sort them without the index, which is way faster. You can see in the explain plan above, that the sort in memory was super fast.

Why You Probably Shouldn’t Do This in Production

This really depends on your data. I knew that only a small percentage of users were experiencing really slow requests due to this query, but I didn’t know what the impact of the + 0 magic would be on users that have fewer activities records. So I ran an experiment using GitHub’s Scientist gem.

The results of the experiment are still coming in, but so far, the original ORDER BY is almost tied with ORDER BY id + 0 for average execution time. However, the 95 percentile execution time (meaning 5% of queries are slower than this number), are way out of sync! ORDER BY id + 0 is almost twice as slow in the 95 percentile category.

The results of the experiment tell me that overall, ORDER BY with an index scan might cause timeouts for some users, but ORDER BY id + 0 with no index scan seems to cause slower queries overall for most users.

Looks like I’m going to have to find a different solution to this problem.

Conclusion

Adding + 0 to your ORDER BY id is a wacky trick that will speed up queries when the index is HUGE and the IDs returned have big intervals.

However, it won’t always work. Indexes are still fast! Test your queries safely in production to make sure that you’re not making a worse experience overall to save a few slow queries.

Two Tools for Diagnosing Slow Endpoints in Rails

Mon, 29 Mar 2021 12:00:00 +0000

Intro

In general, I see two types of slow endpoints when I am doing performance work: endpoints that have bad code causing a slow response, and endpoints that have a bad query causing a slow response. This post will focus on endpoints that have bad code.

Slow endpoints can be identified using an application performance monitor like NewRelic. These endpoints usually either have N + 1 queries, or they spend lots of time in Ruby. You’ll see them in NewRelic, but if you want to hit an endpoint in real-time with production data, see the tip below about Rack MiniProfiler.

NewRelic

The transactions monitor is a good place to start. Pick a broad time range (7 days) and look at the “Transaction Traces” that New Relic has captured. If a transaction trace here includes a long query or lots of queries to the DB, it is likely a good transaction to look into.

There will likely also be some obvious problem queries in the top “Most Time Consuming” transactions. Click through each transaction here and take a look at the transaction traces that NewRelic captured.

The example below has two N + 1 problems! First you see that we hit Memcached 62 times, then we hit the relational database 47 times! Eeep! Looks like this is a good endpoint to work on.

“Most Time Consuming” is not a bad thing. If we have a really fast endpoint that is hit tens of thousands of time per minute, it is not really a problem. But if a relatively busy endpoint has a slow average response time, it likely is a problem!

Rack MiniProfiler

Development and staging data can differ wildly from production data, which makes query performance differ wildly between the environments.

Running Rack MiniProfiler in production gives you a real-time stack trace of live production data! Check out the Rack MiniProfiler docs on how to run it in a production environment

I like to be able to selectively turn Rack MiniProfiler on and off, so I usually set it up so that you have to log in as an admin user and then you have to have turned it on for your session by adding ?rmp=on to the first request.

Once Rack MiniProfiler is turned on, you can hit one of the problem endpoints that you see in NewRelic and get more detailed information on what is slowing that request down.

4 Possible Ways to Resolve Slow Endpoints

This is a non-exhaustive list of possible solutions.

Find an N + 1? Solve it! You’ll see these in either NewRelic or in Rack Mini Profiler. Solving an N + 1 can mean either eager-loading data using includes, or loading the necessary data in a separate query. It’s usually best to start with using includes, and if causes performance issues, try using separate queries.
Add or improve caching
- Can the data being queried be cached, or can you use Russian Doll Caching to cache view partials?
- Can you improve the cache usage by selecting multiple records from the cache rather than doing N + 1 queries to the cache? Check out the docs on select_multi to see how we might resolve the 62 queries to the cache in the example above.
Here’s an odd one that you’ll find in older applications: Do you even need to display this data? Or do you to display this data with the resolution you are showing? Sometimes older pages slow down because we are trying to show a count of all data from the beginning of time!

Remember, performance work can take a few passes to get it right. Try one strategy at a time, deploy, and monitor until your response time is back to an acceptable level.

I’d love to hear your favourite strategies for tackling slow endpoints.

Performance on enumerator.dev

Three Memory Leak Patterns

Normal Memory Usage

Gradual Leak

Spiky Memory Leak

Taste

Taste Does Not Matter, Customers Matter

But insert thing here is BAD!?

Conclusion

Use Precomputed Hashes Instead of BCrypt in Test

Speeding Up willow.camp's post_test.rb by 99%

How Rack::Timeout Keeps Your App Alive

Why Requests Take A Long Time?

How Does This Keep My App Alive if it Kills Things?

When is Rack::Timeout Unsafe?

Where Does Rack::Timeout Run in My App?

Middleware

Middleware is a Trampoline

Common Middleware Mistakes

Not yielding control when you should

Putting timing in the wrong place

Expensive synchronous processing

Ouch! Killing PG Performance with Row-Level Security

What is RLS in Postgres?

Performance Foot-Gun

How to Write a Performant RLS Policy

Can We Make it Faster?

Conclusion

One WEIRD Trick for Speeding Up ORDER BY That You Probably Shouldn't Use

The WEIRD Trick

What in the ACTUAL is happening here?

Why You Probably Shouldn’t Do This in Production

Conclusion

Two Tools for Diagnosing Slow Endpoints in Rails

Intro

NewRelic

Rack MiniProfiler

4 Possible Ways to Resolve Slow Endpoints

But `insert thing here` is BAD!?