{ "version": "https://jsonfeed.org/version/1", "title": "Rails on enumerator.dev", "icon": "", "home_page_url": "https://enumerator.dev/", "feed_url": "https://enumerator.dev/feed.json", "items": [ { "id": "https://enumerator.dev/naming-things-for-what-they-do/", "title": "Naming Things for What They Do", "content_html": "

I just saw the Rails World announcement that flavorjones is working on ActiveRecord::Tenanted and all I can say is, “What a reasonable name!”

\n

When I started willow.camp I chose not to use apartment partially because the name and the metaphor were too confusing. I didn’t like tho have to get used to the idea of requests taking “elevators” and all that. The “apartment” metaphor doesn’t work for databases even though “tenant” does.

\n

Always choose descriptive names over clever ones. It doesn’t matter how well you think the metaphor fits; you’ll always end up with something confusing in the end.

\n", "date_published": "2025-09-09T11:23:33+00:00", "url": "https://enumerator.dev/naming-things-for-what-they-do/", "tags": ["ruby","rails"] }, { "id": "https://enumerator.dev/end-to-end-tests-with-minitest-and-rails/", "title": "End To End Tests with Minitest and Rails", "content_html": "

willow.camp has a small system test suite that runs on CI. It used to use the out-of-the-box settings that come with Rails: Capybara, Selenium, etc.

\n

I noticed a flaky test on CI, which launched a journey to replace Selenium with Cuprite.

\n

Fixing the Flaky Test

\n

I worked through the flaky test with Claude Code, and as Claude was running the tests, I noticed this pop-up from Chrome.

\n
\n

A data breach on a site or app exposed your password…

\n
\n

I don’t use Chrome very often, so this jumped out at me. Of course, I use the oh-so-secret password “password” in my test suite, and Chrome flagged it as unsafe.

\n

Disabling password leak detection fixed this for me.

\n
browser_options: { "disable-features": "PasswordLeakDetection" }\n

But I still got timeouts on CI that looked like the tests were running before the browser was ready.

\n

Waiting for CI is a bit painful. You can see my hilariously bad Git history with Claude’s gleeful overconfidence:

\n
* 0c514d1 - nosandbox (15 minutes ago) <Cassia Scheffer>\n...\n* 57ac55b - bump timeout to 30 sec for ci (21 minutes ago)\n* 9d6e86e - rewirite cuprite/capybara configs (26 minutes ago)\n* 39f3238 - fix: simplify Cuprite configuration following best practices (10 hours ago)\n* 68bfd53 - fix: simplify Cuprite configuration and fix CI timeout issues (24 hours ago)\n* cebfae7 - fix: resolve Cuprite websocket timeout issues in CI (24 hours ago)\n* dc288b7 - fix: make Cuprite configuration more robust for CI environments (24 hours ago)\n...\n* e5bb4df - fix: increase Cuprite timeout and add CI-specific settings for GitHub Acti>\n...\n* cb36eaa - feat: migrate system tests from Selenium to Cuprite (35 hours ago)\n* 39f0ff1 - disable selenium chrome password detection (35 hours ago)\n

That Looks Bad, Cassia. Why Would You Let Claude Do That!?

\n

Because Claude is faster at making mistakes than I am, and I am tired of waiting for CI. Making mistakes quickly means speedier feedback. So I sent Claude off on a fool’s errand to help me learn from the mistakes I would otherwise have made myself.

\n

In the meantime, I read the Evil Martians article about better system tests.

\n

Using Cuprite in Rails with Minitest

\n

The Evil Martians article on system tests uses RSpec, but willow.camp uses Minitest. Here’s what I had to change to make it work with Minitest.

\n

1. PrecompileAssets becomes a module and gets called when setup runs.

\n
# Precompile assets before running tests to avoid timeouts.\n# Do not precompile if webpack-dev-server is running (NOTE: MUST be launched with RAILS_ENV=test)\n\nmodule PrecompileAssets\n  def self.setup\n    # Check if we're running system tests by looking at the test files being loaded\n    running_system_tests = caller.any? { |line| line.include?("test/system") } ||\n      ARGV.any? { |arg| arg.include?("test/system") } ||\n      ENV["RAILS_TEST_TYPE"] == "system"\n\n    unless running_system_tests\n      puts "\\n🚀️️  No system test selected. Skip assets compilation.\\n"\n      return\n    end\n\n    puts "\\n🐢  Precompiling assets.\\n"\n    original_stdout = $stdout.clone\n\n    start = Time.current\n    begin\n      $stdout.reopen(File.new(File::Constants::NULL, "w"))\n\n      require "rake"\n      Rails.application.load_tasks\n      Rake::Task["assets:precompile"].invoke\n    ensure\n      $stdout.reopen(original_stdout)\n      puts "Finished in #{(Time.current - start).round(2)} seconds"\n    end\n  end\nend\n\n# Run the setup when this file is loaded\nPrecompileAssets.setup if defined?(Rails)\n

2. BetterRailsSystemTests Becomes a Moduel

\n
module BetterRailsSystemTests\n  # Make failure screenshots compatible with multi-session setup.\n  def take_screenshot\n    return super unless Capybara.last_used_session\n\n    Capybara.using_session(Capybara.last_used_session) { super }\n  end\nend\n

3. Modules are included in ApplicationSystemTestCase

\n
require "test_helper"\nrequire "capybara/cuprite"\nrequire_relative "system/system_helper"\n\nclass ApplicationSystemTestCase < ActionDispatch::SystemTestCase\n  include BetterRailsSystemTests\n  include CupriteHelpers\n\n  driven_by Capybara.javascript_driver\n\n  def setup\n    super\n    # Use JS driver always\n\n    # Store original host for cleanup\n    @original_host = Rails.application.default_url_options[:host]\n    # Make urls in mailers contain the correct server host.\n    # This is required for testing links in emails (e.g., via capybara-email).\n    Rails.application.default_url_options[:host] = Capybara.server_host\n  end\n\n  def teardown\n    # Restore original host\n    Rails.application.default_url_options[:host] = @original_host\n    super\n  end\nend\n

Flakiness Still Included on CI

\n

I still see a bit of system test flakiness on CI, but far less than before. I am running on the default GitHub Actions runner, which is pretty small. So there’s a good chance that the flakiness is due to low resources on the machine. So far, tests have consistently passed when I run these on my M1 MacBook Air.

\n

I’ll dig into these flaky tests another day! But this looks like an improvement overall to me!

\n", "date_published": "2025-08-13T22:27:26+00:00", "url": "https://enumerator.dev/end-to-end-tests-with-minitest-and-rails/", "tags": ["willow-camp","rails","capybra","minitest"] }, { "id": "https://enumerator.dev/use-precomputed-hashes-instead-of-bcrypt-in-test/", "title": "Use Precomputed Hashes Instead of BCrypt in Test", "content_html": "

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.

\n

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

\n

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

\n
\n

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") %>.

\n

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

\n

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.

\n
\n", "date_published": "2025-07-21T00:55:00+00:00", "url": "https://enumerator.dev/use-precomputed-hashes-instead-of-bcrypt-in-test/", "tags": ["willow-camp","performance","ruby","rails"] }, { "id": "https://enumerator.dev/speeding-up-willow-camp-s-post_test-rb-by-99/", "title": "Speeding Up willow.camp's post_test.rb by 99%", "content_html": "

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.

\n

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

\n
\n

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

\n

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

\n

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

\n\n
\n

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.

\n

Thanks Claude!

\n", "date_published": "2025-07-20T14:05:00+00:00", "url": "https://enumerator.dev/speeding-up-willow-camp-s-post_test-rb-by-99/", "tags": ["willow-camp","performance","ruby","rails"] }, { "id": "https://enumerator.dev/introducing-willow-camp/", "title": "Introducing willow.camp", "content_html": "

I’ve been working on a side project and am finally ready to share it! My blog, enumerator.dev, is now hosted on my platform called willow.camp.

\n

willow.camp started because I wanted a platform that felt like me. I wanted a simple editing interface, the ability to import and export every post in markdown, and a pared-down reading interface.

\n

My blog was previously hosted on Ghost, but the experience felt like an “influencer” blog to me. I’m a regular developer sharing the projects I work on, and I don’t need a big newsletter distribution list or metrics on open rates.

\n

I looked at bearblog.dev and pika.page as alternatives to Ghost. They are both lovely platforms, and willow.camp is inspired by them, but they didn’t quite meet my needs. So I took the plunge and typed rails new willow_camp in my terminal.

\n

Well, okay, I admit. First, I tried Elixir; then I read about doing it in Rust and tested out Hanami before realizing that I wanted to create something more than I wanted to learn a new language.

\n

Sometimes speed is about using a batteries-included framework more than it is about milliseconds of server render time.

\n

The willow.camp Stack

\n

willow.camp is built on Rails 8, Turbo, Hotwire, Stimulus, and DaisyUI. These libraries have made it easy to spin up scaffolding and prototype ideas. A considerable part of the initial commits in willow.camp are all rails scaffold (not even AI!). As things took shape, I polished off features using context7 to pull docs into Zed hooked up to GitHub Copilot.

\n

So far, here are a few libraries I’ve used to develop willow.camp:

\n\n

Hosting

\n

willow.camp is hosted on a DigitalOcean instance with a managed Postgres database. Deployments and configs are managed through hatchbox.io.

\n

APM, Errors, Emails

\n

I hooked up Scout Monitoring for APM and Honeybadger for error tracking. For now, I’m well below the usage limit for both, so I’m on the free plan. I’m happy with both of those, but I find the log management in Scout to be somewhat clunky on my tiny MacBook Air’s screen. I’m not sure I’d pay for the logging aspects of Scout, but everything else meets my needs.

\n

Password reset emails are sent through loops.so. Loops was straightforward to set up, and transactional emails are free.

\n

Dashboard

\n

As mentioned above, the editing interface is marksmith, an easy-to-use, plug-and-play markdown editor with a built-in preview feature. Posts are saved in both markdown and HTML formats. This makes exporting content through the API straightforward because Markdown is the base format in which posts are written and saved. HTML is only used for display.

\n

Mermaid Diagrams

\n

You can add a code block with mermaid as the language, which will render a mermaid diagram on the page in place of the code block. Have a look at How Rack::Timeout Keeps Your App Alive for an example.

\n

Auto-saving Posts

\n

I like to start a draft post, then walk away and think about it. While I enjoy writing in Obsidian, I often use my blog “drafts” as a place to store ideas.

\n

I added a stimulus controller that auto-saves draft posts. It checks if the post is “dirty” (i.e., changed since the last save) and saves it every 60 seconds. You can also hit Command/Control + S to save while you type.

\n

Auto-save is disabled on “published” posts because I wouldn’t want a half-edited post to be saved and published.

\n

No Image Hosting

\n

I don’t host images or static content aside from what’s in the Rails asset pipeline. This is intentional right now. I want to keep hosting complexity to a minimum, and I didn’t want to worry about storage services, mounting volumes, or data retention. For now, I’d like the server to be ephemeral.

\n

Favicons, Themes, Subdomains, & Custom Domains

\n

Of course, I spent the most time on the settings page.

\n

You can preview custom favicons and themes on the willow.camp home page by clicking the menu items in the top right. The themes come from DaisyUI. The favicon functionality still requires some refinement.

\n

How willow.camp (sort of) Generates Favicons

\n

Users can insert any emoji into the “favicon” settings form. The emoji is saved to their settings, and then when the page loads, it is rendered in in-memory canvases to generate the various sizes of favicons needed and insert them into the head as an image in a URI scheme like so:

\n
<link type="image/png" rel="icon" sizes="16x16" href="data:image/png;base64,...lots of characters=">\n

This works for most cases, but since the image doesn’t exist until the JS renders it, some browsers may not display a favicon at all, and there are no Open Graph images available for link previews on social sites.

\n

Better Favicons in the Future

\n

I want to fix the favicon functionality. I think the best way to do this reliably is to pre-generate images for 10-20 emojis that users can pick from. This way, I only have to store a set number of assets on the server and can provide real links to favicon images.

\n

Another possibility is to render a canvas in the browser when the user selects the desired emoji. Then, when they update their settings, save the favicon as an attachment and generate the correct sizes on the server. This would provide flexibility to use any emoji, but it would also require hosting more static content, which I didn’t want to do yet.

\n

Themes

\n

The DaisyUI themes are fun! I borrowed their theme picker HTML and used a Stimulus controller to give instant previews of each theme. Users’ theme preferences are saved in the DB and rendered in the HTML.

\n

I experimented with allowing users to choose between a light and dark theme, but couldn’t get it to work to my satisfaction. prefers-colour-scheme works great with DiasyUI’s default light and dark, but I didn’t see an easy way to pass a user’s preferences from the database into the CSS without compiling the assets on each request.

\n

I did have a light/dark functionality sort of working with a Stimulus controller and some data attributes in the HTML, but there was a brief flash of the default light or dark scheme before the chosen scheme was loaded.

\n

For now, you can pick one colour scheme for your willow.camp blog.

\n

Subdomains and Custom Domains

\n

Thanks to hatchbox’s Caddy setup, subdomains and custom domains are served over HTTPS. Each blog has a subdomain like cassia.willow.camp and an optional custom domain like enumerator.dev. Users point a CNAME record to their subdomain to set up a custom domain name.

\n

SEO

\n

It has been nearly a decade since I had to think about SEO. I’ve added Open Graph tags to the pages, and every site gets a sitemap.xml and robots.txt. I tried to use semantic HTML as best I could and asked Claude to audit the pages.

\n

No Analytics

\n

I had plausible.io on my blog for a very brief period, but the analytics provided too much information for me. I just want to share what I write. I don’t need graphs.

\n

If you want to use willow.camp for your blog and want analytics, let me know, and I can add a feature to let you insert the code you need.

\n

Accessibility

\n

I need to do another accessibility audit on willow.camp. I tried to ensure the HTML used aria labels that were clear and concise.

\n

I recently found CapybaraAccessibilityAudit, which I’ll use to audit the dashboard and public-facing pages.

\n

About Page

\n

The “about” page is a bit of a hack. “Pages” and “Posts” are almost the same thing in the database. I used single table inheritance to create a single “about” page for each user. Every user always has one about page. If you delete your “about” page, a new draft page is created in the background.

\n

willow.camp doesn’t use pages otherwise. Everyone gets one “about” page.

\n

Feeds: RSS, Atom, JSON

\n

RSS and the indie web are having a comeback. I’ve been reading RSS on Feeeed and Feedbin lately, so proper feeds are essential to willow.camp.

\n

My pet peeve with “follow me on RSS” links is that most of the time, you end up downloading a file when you click on the link. That’s not helpful.

\n

I drew inspiration from Subscribe Openly and created a helpful “Subscribe” page with clipboard helpers to copy the feed of your choice easily. Check it out: enumerator.dev/subscribe.

\n

API and CLI

\n

willow.camp comes with an API and CLI tool for managing content. I’ve used the CLI to import and format my content from Ghost.

\n

The CLI converts most of the HTML from Ghost correctly, but leaves some extraneous markdown that requires manual cleanup.

\n

Todo list

\n

I have lots of things I still want to do on willow.camp. Here are a few things I have in mind:

\n\n

New Features

\n\n

Thoughts on Stimulus, Hotwire, and Turbo

\n

Wow. I love this. Honestly, it makes me love developing web apps again. There is no heavy complexity between the frontend and backend. You don’t need to shift mindsets to start writing in a frontend framework.

\n

I didn’t expect to enjoy these features this much. However, I’m back to writing HTML that maps directly to what I see in the browser, and a few extra bits of syntax in data-attribute fields make it a snappy and dynamic UI.

\n

willow.camp is Free

\n

willow.camp is free to use. If people find it useful, I might introduce a paid tier to cover hosting costs.

\n

If you want a willow.camp blog, you can sign up and try it out.

\n", "date_published": "2025-06-28T20:06:00+00:00", "url": "https://enumerator.dev/introducing-willow-camp/", "tags": ["turbo","stimulus","willow-camp","rails"] }, { "id": "https://enumerator.dev/how-rack-timeout-keeps-your-app-alive/", "title": "How Rack::Timeout Keeps Your App Alive", "content_html": "

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.

\n

Why Requests Take A Long Time?

\n

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.

\n

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

\n

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.

\n

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

\n

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

\n

When is Rack::Timeout Unsafe?

\n

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.

\n

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

\n

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.

\n

Where Does Rack::Timeout Run in My App?

\n

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.

\n

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

\n

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

\n
graph TD\nClient[Client Requests] --> LB[Load Balancer\nnginx/HAProxy]\nLB --> Container1[Container 1\nRails App]\nLB --> Container2[Container 2\nRails App]\nContainer1 --> PumaServer1[Puma Server 1]\nContainer2 --> PumaServer2[Puma Server 2]\nPumaServer1 --> Worker1_1[Worker 1]\nPumaServer1 --> Worker1_2[Worker 2]\nPumaServer2 --> Worker2_1[Worker 1]\nPumaServer2 --> Worker2_2[Worker 2]\nWorker1_1 --> RackTimeout1_1[Rack::Timeout\nMiddleware]\nWorker1_2 --> RackTimeout1_2[Rack::Timeout\nMiddleware]\nWorker2_1 --> RackTimeout2_1[Rack::Timeout\nMiddleware]\nWorker2_2 --> RackTimeout2_2[Rack::Timeout\nMiddleware]\nRackTimeout1_1 --> Threads1_1[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout1_2 --> Threads1_2[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout2_1 --> Threads2_1[3 Threads\nThread Pool\n_timeout monitored per thread_]\nRackTimeout2_2 --> Threads2_2[3 Threads\nThread Pool\n_timeout monitored per thread_]\nclassDef container fill:#e1f5fe\nclassDef worker fill:#f3e5f5\nclassDef thread fill:#e8f5e8\nclassDef loadbalancer fill:#fce4ec\nclassDef middleware fill:#fff3e0\nclass Container1,Container2 container\nclass Worker1_1,Worker1_2,Worker2_1,Worker2_2 worker\nclass Threads1_1,Threads1_2,Threads2_1,Threads2_2 thread\nclass LB loadbalancer\nclass RackTimeout1_1,RackTimeout1_2,RackTimeout2_1,RackTimeout2_2 middleware
\n", "date_published": "2025-06-05T00:00:00+00:00", "url": "https://enumerator.dev/how-rack-timeout-keeps-your-app-alive/", "tags": ["performance","ruby","rails"] }, { "id": "https://enumerator.dev/migrating-from-standalone-sidekiq-to-an-activejob-adapter/", "title": "Migrating from Standalone Sidekiq to an ActiveJob Adapter", "content_html": "

I paired on this problem with my coworker Hannah Yeates. The examples below are from this pairing session. Thanks for working on this together, Hannah!

\n
\n

I am working on a project right now that uses Sidekiq without the ActiveJob adapter. This means that our Sidekiq jobs look something like this:

\n
class ExampleWorker\n  include Sidekiq::Worker\n\n  def perform(arg)\n    puts "Hello, the arg was #{arg}"\n  end\nend\n

And we call them like this:

\n
ExampleWorker.perform_async("a nice arg")\n

And in dev they’ll execute like this:

\n
2024-01-17T15:05:31.455Z pid=45599 tid=18gj\n  class=TestWorker \n  jid=8d32dcd88b1de2ed3a5419eb \n  INFO: start\nHello, the arg was foo\n

However, we want to switch over to GoodJob so that we have a transactionally safe background job processor. Our steps for doing this are:

\n
    \n
  1. Set up Sidekiq as an ActiveJob adapter instead of using Sidekiq on its own.
    2. \n
  2. Install GoodJob and replace Sidekiq with GoodJob.
    3. \n
  3. Run Sidekiq and GoodJob in parallel so that Sidekiq finishes all the work in Redis.
    4. \n
  4. Shut down Sidekiq and remove it from the application code.
    5. \n
\n

This post is about step 1, making Sidekiq the ActiveJob adapter instead of using it on its own.

\n

Step 1 : Configure ActiveJob

\n

Our first step is to configure the application to use Sidekiq for ActiveJob

\n
# in application.rb\nconfig.active_job.queue_adapter = :sidekiq\n

Then we created an empty ApplicationJob (more on this later).

\n
# application_job.rb\nclass ApplicationJob < ActiveJob::Base\n  # leave this empty for now\nend\n

Step 2: Convert Workers to ApplicationJob

\n

Next we updated our jobs to inherit from application job:

\n
class ExampleWorker < ApplicationJob # Add this\n  # remove this: include Sidekiq::Worker\n\n  # The rest of the code remains the same\nend\n

And finally, we changed all our method calls from ExampleWorker.perform_async("a nice arg") to ExampleWorker.perform_later("a nice arg").

\n

Step 3: See What Breaks

\n

So far, so good! Next, we had a question: What happens when a job is enqueued by Sidekiq but processed by ActiveJob? To emulate this we:

\n
    \n
  1. Booted a Rails console locally.
    2. \n
  2. Use the original code to enqueue a job.
    3. \n
  3. Modify the worker to use ApplicationJob.
    4. \n
  4. Boot Sidekiq locally and see what errors we get.
    5. \n
\n

In the real world, this would happen when the new code is deployed and there are jobs in the queue that were put there by Sidekiq. Here’s the first error we got:

\n
WARN: NoMethodError: undefined method `jid=' for #<TestWorker:...>\n

We resolved this by creating an alias to ActiveJob’s provider_job_id= and tested again. In the end we had three NoMethodError messages to resolve. We updated our ApplicationJob to respond to those methods.

\n
class ApplicationJob\n  def jid=(arg)\n    provider_job_id = arg\n  end\n\n  def jid\n    provider_job_id\n  end\n\n  def bid=(arg);\n    # We are lucky to not need batching, so we let this return `nil`\n  end\nend\n

Wrapping Up

\n

Making the switch to ActiveJob was easier than we expected. We now have a backwards compatible way of moving from standalone Sidekiq to ActiveJob. Our next step is to swap out Sidekiq for GoodJob.

\n

If you are planning on using GoodJob, or Solid Queue, check out this article on making the switch once you’re using ActiveJob:

\n

Migrating from Sidekiq to Solid Queue | Kyle Keesling

\n", "date_published": "2024-01-17T00:00:00+00:00", "url": "https://enumerator.dev/migrating-from-standalone-sidekiq-to-an-activejob-adapter/", "tags": ["sidekiq","activejob","ruby","rails"] }, { "id": "https://enumerator.dev/two-tools-for-diagnosing-slow-endpoints-in-rails/", "title": "Two Tools for Diagnosing Slow Endpoints in Rails", "content_html": "

Intro

\n

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.

\n

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.

\n

NewRelic

\n

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.

\n

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.

\n

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.

\n

\n

“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!

\n

Rack MiniProfiler

\n

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

\n

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

\n

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.

\n

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.

\n

4 Possible Ways to Resolve Slow Endpoints

\n

This is a non-exhaustive list of possible solutions.

\n\n

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.

\n

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

\n", "date_published": "2021-03-29T12:00:00+00:00", "url": "https://enumerator.dev/two-tools-for-diagnosing-slow-endpoints-in-rails/", "tags": ["performance","ruby","rails"] } ] }