Ruby and Rust developer specializing in backend performance - Paweł Urbanek

Using LLMs and MCP to Debug PostgreSQL Performance in Rails

Tue, 22 Jul 2025 00:09:04 +0200

I’ve recently automated a large portion of my Rails performance audits. In this tutorial, I’ll describe how to configure an AI-powered PG performance debugging. We will cover using LLMs with custom MCP (model context protocol) n8n integration. We will also discuss the legal and security implications of connecting AI to the production database.

How to optimize PostgreSQL performance with AI?

I’m not sure if the current blogosphere needs yet another introduction to MCP. Instead, here’s a sneak peek of what we will be building in this tutorial:

TLDR Slack bot debugging PG performance.

A Slack bot connected to the PostgreSQL database? Can it run arbitrary SQL queries? Does it send production data to OpenAI servers? Is it any good in nontrivial Rails apps? Will it yolo a DROP TABLE on prod at 3 AM?

Let’s answer all these questions.

Debugging context provided by the pg-extras gem

Copy-pasting queries from heroku-pg-extras one weekend turned out to be a good thing. I’ve been maintaining the rails-pg-extras gem for over 6 years now. The project’s relative popularity helped me onboard multiple clients and earn a living as a Rails performance consultant for over four years.

A significant part of my performance audits and subsequent retainer offering was interpreting the output of the pg-extras gem. It currently exposes ~40 methods. A solid entry point is the diagnose method, which aggregates over a dozen checks to produce a report about the database health. By configuring the web interface, you can get a nice dashboard:

rails-pg-extras web dashboard diagnose report

Rails projects with a dynamic development pace and sizeable traffic are likely to discover new db-level inefficiencies every week. But, deep dive into metadata exposed by the pg-extras API can be tedious and repetitive process.

Here’s where a brand new rails-pg-extras-mcp gem makes an entrance.

Automating pg-extras Performance Debugging with LLMs

rails-pg-extras-mcp is a relatively simple (~300 boilerplate LOC total) wrapper on top of rails-pg-extras. It exposes the API in a format digestible by LLMs. By connecting it to your AI model of choice, you can automate the repetitive task of hunting for inefficiencies in the database layer.

This gem is a core component of the previously showcased Slack bot demo. Slack bot is just an arbitrary choice of interface, configured with the help of the n8n platform:

rails-pg-extras MCP with Slack bot n8n schema

MCP protocol is universal, so you can use it with local Cursor IDE, Claude Code, OpenAI API, basically any modern LLM.

Claude Desktop rails-pg-extras MCP integration

I like the Slack bot interface because it works well for team collaboration. Realistically, you cannot expect LLM to resolve PostgreSQL issues with 100% accuracy. However, the usual bottleneck of working with pg-extras is making sense of its verbose output. A raw output is often illegible:

Raw rails-pg-extras output

LLMs do a fantastic job, extracting useful info from raw data and reformatting it to vastly simplify human analysis. I’ve configured the demo Slack bot to only reply if mentioned by the @n8n handle. A development team can discuss ongoing db issues on a dedicated channel and augment context by predigested metadata from the LLM.

LLM-powered PG debugging session

Please remember the Slack bot this is just a choice of interface. You can configure LLMs to email you weekly database healthcheck reports PDF, talk to the database directly from the Cursor IDE chatbox etc.

So it looks pretty cool, but can you use it on production without summoning the GDPR police?

Legal and security concerns of using LLMs with production data

DISCLAIMER: I’m not a lawyer, and this is not legal advice. Please do your own research before exposing any sensitive data to LLMs.

rails-pg-extras core component is ruby-pg-extras gem. It defines metadata queries with performance debug data.

METADATA is an critical keyword here. It means that you can use rails-pg-extras MCP integration without giving LLMs access to ANY business logic-related tables. Additionally, even query argument values are not exposed. Here’s a sample output excerpt of the calls method, which lists top bottlenecks:

SELECT first_name, last_name, email FROM customers WHERE email LIKE $1 ORDER BY last_name LIMIT $2     
SELECT * FROM orders WHERE order_date >= $1 ORDER BY order_date DESC LIMIT $2                          
SELECT * FROM customers WHERE loyalty_points > $1 ORDER BY loyalty_points DESC LIMIT $2

As you can see, values are replaced by $1, $2 placeholders. It means that in the default rails-pg-extras-mcp configuration, LLMs cannot read any sensitive data.

To strengthen this assumption, you can configure a dedicated user with read access only to the metadata tables:

CREATE ROLE extras_viewer NOLOGIN;
CREATE USER extras_user WITH PASSWORD 'your_password';
GRANT extras_viewer TO extras_user;

GRANT CONNECT ON DATABASE your_db_name TO extras_user;
GRANT USAGE ON SCHEMA public TO extras_user;

GRANT SELECT ON pg_stat_statements TO extras_user;
GRANT SELECT ON pg_stat_activity, pg_locks TO extras_user;
GRANT SELECT ON pg_stat_user_indexes, pg_index TO extras_user;
GRANT SELECT ON pg_stat_all_tables, pg_stat_database, pg_settings, pg_namespace TO extras_user;

GRANT EXECUTE ON FUNCTION pg_relation_size(regclass) TO extras_user;
GRANT EXECUTE ON FUNCTION pg_indexes_size(regclass) TO extras_user;
GRANT EXECUTE ON FUNCTION pg_table_size(regclass) TO extras_user;
GRANT EXECUTE ON FUNCTION pg_total_relation_size(regclass) TO extras_user;

and configure the ENV value:

export RAILS_PG_EXTRAS_MCP_DATABASE_URL=postgres://extras_user:your_password@localhost:5432/your_db_name

I’m not sure if it’s enough to keep the GDPR inspectors happy. But, it’s an order of magnitude safer compared to letting LLMs roam free with a full-blown read-write db access.

Enabling optional EXPLAIN ANALYZE mode

If you feel adventurous, you can toggle PG_EXTRAS_MCP_EXPLAIN_ENABLED and PG_EXTRAS_MCP_EXPLAIN_ANALYZE_ENABLED flags. They add explain and explain_analyze tools to the MCP interface:

LLM running EXPLAIN ANALYZE on a bottleneck query

This feature allows LLMs to run EXPLAIN and EXPLAIN ANALYZE on selected SQL queries. Hand-crafting queries for such analysis by replacing $1, $2 placeholders with matching data can be a little tedious and time-consuming. LLMs do a fantastic job automating this process.

A critical difference is that it requires read access to the underlying tables. And while EXPLAIN outputs the only theoretical execution plan, EXPLAIN ANALYZE runs the actual query and reports real execution metrics. It comes with an increased risk of potentially exposing sensitive data to the LLMs. Or even writing to the database if you forget to configure read-only access. I did put some effort into preventing LLMs from injecting malicious SQL.

No hesitation

But I wouldn’t bet that a crafty LLM cannot sneak a DROP TABLE SQL injection past these safeguards. If you have feedback on how this security layer could be improved, please get in touch.

How much does it cost?

So far, I’ve had the most success with OpenAI gpt-4o model. During the two weekends I spent testing the setup, sending ~200 Slack messages, I managed to rack up a whopping total of $1.56 in API charges.

Anthropic models seem significantly more expensive. Claude Sonnet 4 costs ~$0.05 per chat message, and Claude Opus 4 devoured $1 for a single performance analysis. I was unable to distinguish the difference in quality of output depending on the model, but I did not spend much time cross-testing them. An interesting strategy could be to use a pricey deep-thinking model for weekly performance reports, and a cheaper one for everyday chat usage.

On top of that you’ll need an n8n instance for ~$20 month, but you can also self-host it.

Summary

Make sure to check out the rails-pg-extras-mcp readme for info on how to use it with your Rails app. The project in an early POC stage, so contributions are welcome.

A Slack bot, some LLM magic, a few hundred lines of glue code, and just like that… I’ve automated myself out of PG consulting gigs. The future looks scary. I’ll be off now to practice my plumbing skills.

My puts Debugging Workflow in Rails Apps

Mon, 19 May 2025 07:58:21 +0200

Puts debugging is the best. In this tutorial, I’ll walk you through my workflow for debugging Rails codebases using a custom toolkit inspired by Rust. We will also discuss how to smuggle your debug tools, through even the most rigorous code review process.

Why and how to puts debug Ruby code?

I’ve never been a fan of (or properly learned) using debug breakpoints. While I sometimes use ruby debug, most of the time, I’m a puts debugger.

My favorite way to debug is via an automated test suite. I usually have the retest gem running in the background to automatically execute relevant tests on each file save. If I need to narrow the scope, I use a shortcut to copy the current filename with the line number and run a single test:

rs spec/models/user_spec.rb:42

rs is a alias for bundle exec rspec

So far, I’ve relied on quick-and-dirty print statements like these:

p '!!!!!!!!!!!!!!'
p 'first_user', first_user
p 'second_user', second_user
p '!!!!!!!!!!!!!!'

Please don’t tell me you haven’t written something like this before. It highlights a few issues with the default way to debug in Ruby.

!!!!!!!!!!!!!!! - annotation is often needed. p debug statements don’t stand out enough in a verbose test/logs output.

p 'first_user', first_user - manually adding labels is necessary to identify which debug statement is which.

p method calls are hard to clean up later since they might already exist elsewhere in the codebase.

Introducing `dbg-rb` - a simple Ruby puts debugging helper

Recently, I’ve been writing more Rust than Ruby. I really came to appreciate its built-in dbg! macro:

#[derive(Debug)]
struct User {
    username: String,
    password: String,
    active: bool,
}

fn main() {
    let user = User {
        username: "user1".to_string(),
        password: "password1".to_string(),
        active: true,
    };

    dbg!(user);
}

// [src/main.rs:15:5] user = User {
//     username: "user1",
//     password: "password1",
//     active: true,
// }

It produces a verbose, source-located output, together with the name of the variable. Coming back to Ruby, it felt odd that such a simple and handy helper isn’t available out of the box.

Hence, the birth of the dbg-rb gem. It’s my attempt to recreate the Rust dbg! macro in Ruby:

dbg(User.last(2).map(&:as_json)) 

It prints the filename, line number, and source expression — all with colored output for quick scanning. It also works for method and keyword arguments. For me, knowing the source location and seeing labeled variables names makes debugging faster and far more pleasant to work with. What’s more, the dbg method is unique, so it’s trivial to grep and clean up after use.

For more details and configuration options, check out the documentation in the dbg-rb repo.

How to use dbg-rb in Rails without adding it to the Gemfile?

I find dbg-rb useful in my everyday Rails work. But I understand that not all the devs will share this enthusiasm. When doing performance audits, I needed a way to use this tool without cluttering the dependency list — especially in teams that are strict about gem additions.

In theory it’s possible to add dbg-rb to the IRB config to include it in the Rails console context. But it has little value; I rarely debug directly in the console. I use a test suite for that. It means that dbg-rb has to be available in the bundle exec context. But how can you add a gem to the Gemfile without modifying it?

In theory, I could use a local development branch with a custom Gemfile, but cherry-picking changes before submitting a PR is cumbersome.

Here’s a hack that I came up with. It’s similar to my previous post on Rails debug aliases. You can inject dbg-rb into a Rails app via a local initializer file that’s ignored by Git globally.

Start by creating the file with the following contents:

~/.gitignore_global

config/initializers/dbg_rb.rb

Now configure your git to use it:

git config --global core.excludesfile ~/.gitignore_global

Next you can add an inlined lite version of the dbg-rb file to your Rails app initializers folder:

wget https://raw.githubusercontent.com/pawurb/dbg-rb/refs/heads/main/inline/dbg_rb.rb -O config/initializers/dbg_rb.rb

That’s it! You can now use dbg to debug local variables and parameters with automatically appended labels:

dbg user 
# [spec/user_spec.rb:20] user = #<User id: 1, team_id: 1, slack_id: "develop", pseudonym: ...

None of these steps leaves a trace in the git diff, so you can apply it to any Ruby/Rails project without a code review process. Debug tools like this are safe for local use. But be cautious if you’re introducing less obvious techniques — always consult your team before adding anything bypassing standard workflows.

Summary

I find the additional context provided by dbg-rb gem helpful for non-trivial debugging sessions. And if you’re a “vibe debugger”, feeding this extra info to the LLMs increases your chance to quickly produce a correct answer. I wish a similar tool was available by default like in Rust. Unfortunatelly, this Ruby feature proposal has received little traction so far. If you have suggestions for improving dbg-rb — feedback, PRs, and bug reports are always appreciated.

Lessons Learned Migrating my SAAS to Rails 8

Tue, 14 Jan 2025 08:29:37 +0100

My side project Abot for Slack, has been around for ~7 years, i.e., since Rails 5.1. It’s now yielding passive income while running on an almost complete autopilot. But I’m still keeping its dependencies up-to-date. The recent migration to Rails 8 was arguably the most impactful in the app’s lifetime. In this blog post, I’ll describe features introduced in the newest version of the framework and how they affected my project.

Kamal vs Dokku

TLDR initial impressions migrating Abot from Dokku to Kamal: it’s better, apart from one major flaw.

Abot started as a weekend project deployed to Heroku free dynos. Later, I migrated it to AWS EC2 with the RDS PostgreSQL database using Dokku.

The initial Dokku setup long long time ago

Dokku requires a bit more dev-ops expertise than PAAS solutions, but after the initial setup, it offers a workflow almost identical to Heroku. I’ve used Dokku for over 4 years, and it provided a seamless deployment experience with very few glitches along the way. This is one of the OS projects that I regularly donate to.

But the times are changing, and Kamal is a fancy new tool that everyone is talking about.

Kamal’s great advantage is a declarative one-file config, providing an instant overview of the current state of the project. With Dokku, similar insight is scattered across several commands.

Another benefit is seamless deployment setup. Just point Kamal to a barebones VPS, and everything gets deployed via a single kamal setup command. Dokku requires manual installation on the server unless configured with a custom Ansible playbook or similar tool.

Yet another win for Kamal is support for multi-server architecture. With Dokku, you’re limited to single server deployments, so you have to fit all the services, including databases, caches, etc., on a single VPS.

One thing that’s missing from Kamal is the built-in Nginx integration. Dokku provides a customizable Nginx template allowing for fine-tuned configuration of headers, SSL, compression, etc. With Kamal, you’d need to manually configure Nginx in front of the proxy to achieve the same effect. Apparently, the thruster gem can provide similar features as Nginx, but I have not explored it yet. In the end I’ve reimplemented each of the Nginx config tweaks directly in Rails or Cloudflare.

But here comes the previously mentioned major flaw.

Kamal registry-based deployments

Dokku uses a git-based deployment flow, i.e. each git push triggers a new docker image build combining the base image with app-specific Dockerfile. A new docker image is built directly on the target VPS and kept locally.

Kamal requires a nonoptional registry.server (defaults to "hub.docker.com"), registry.username, registry.password config values. These are credentials for one of the commercial (DockerHub, GitHub, Digital Ocean) or custom docker registry service. It’s possible to spin up your own registry, but it’s cumbersome. Built images are pushed to the registry and later downloaded by a target host.

An issue is that the default Kamal configuration exposes Rails application source code in a public image hosted on Docker Hub. In theory, it could leak nonpublic projects if someone followed the Kamal tutorial without analyzing each step. I wish the Kamal team was more explicit about this behavior in the docs and learning materials.

A way to prevent exposing project source code is manually creating the private image up-front or changing the default visibility in DockerHub settings:

DockerHub image privacy settings

A free DockerHub account can host only a single private image. Even the $11/month plan offers only 5GB storage, so with image sizes at ~1GB it might not be enough. A $16/month offer with 50GB space for private images could be necessary for many users. It might not seem expensive. But a choice between exposing source code or incurring monthly costs could be discouraging for someone just exploring the Rails stack.

Fortunately, there are rumors about the Kamal team working on a way to deploy containers, without relying on 3rd party commercial services. In my opinion, this change would significantly enhance Kamal’s appeal.

Goodbye Redis

Since I started working in Rails around a decade ago, the Redis + Sidekiq combo was the de-facto standard for most projects. Rails 8 challenges this status quo by defaulting to the solid_queue gem for background processing. Solid Queue uses SQL database storage instead of Redis. Together with mission_control-jobs UI it’s a drop-in replacement for Sidekiq. It means that we can now get rid of another process and dependency to maintain.

Caching was another area where I’ve seen widespread use of Redis. On the side node, reusing the same Redis instance for both Sidekiq and caching has always been a fun source of sneaky bugs when both processes’ data interfere despite the namespaces…

(╯°□°)╯︵ ┻━┻

Past traumas aside, with the introduction of solid_cache gem modern Rails apps can remove Redis from their stack, simplifying the infrastructure. While conducting my Rails performance audits, I’ve seen projects where Redis was responsible for a significant portion of monthly infra costs. Migrating to SQL-based solutions can result in a major cost reduction for many Rails projects. Also, as per Rails 8 marketing: “you can now cache weeks instead of hours worth of data”.

Here’s a breakdown of monthly AWS cost for ElastiCache Redis with a specified RAM vs RDS database disk space:

Size	Redis RAM	RDS disk space
1.3GB	~$23	~$0.16
6.3GB	~$110	~$0.78
52GB	~$900	~$6.5
210GB	~$3300	~$26

Size values were chosen to find matching ElastiCache instance

RDS incurs additional db instance costs, but on a larger, scale they will be insignificant. Cache-specific databases execute only simple queries over well-indexed tables, i.e. no joins or seq scans. That’s why caching database CPU/RAM can usually be much smaller than primary. But, workload and traffic patterns differ for each project, so please run your benchmarks before making any production infra changes. More cost-aware projects can also squeeze both databases on a single RDS instance.

I did calculations for ElastiCache, so you could slightly reduce the cost by running Redis on EC2 instances. But RAM will always be an order of magnitude more expensive than disk space.

I’ve seen comments that migrating to “non-memory” cache storage will result in a performance drop. So let’s see the numbers in action.

Measuring non-memory caching performance

I’ve run the following benchmark script against different Rails cache stores:

keys = []
json = File.read("sample.json")
Benchmark.bm do |x|
  x.report("cache") do
    2000.times do |i|
      if i % 5 == 0
        key = "test-#{i}"
        Rails.cache.write(key, json)
        keys << key
      end

      Rails.cache.read(keys.sample)
    end
  end
end

Please take this benchmark with a grain of salt. It’s a straightforward script that does not simulate how the cache store behaves under a constant load or when there’s more data.

It distributes read and write operations in 80/20 relation. Here’s the result for different store types:

Store	Total time	Avg. time
FileStore EBS	20.0s	~4ms
Redis/Memcache	20.1s	~4ms
FileStore EFS	22.4s	~4.5ms
SolidCache SQLite	24.4s	~4.8ms
SolidCache PG	27.05s	~5.4ms

For me, the main takeaway from the above table is that in the context of web applications, the caching layer is fast enough, regardless of the underlying store type. The amount of data that can be cached is vastly more important than sub-millisecond performance improvements.

Although the in-memory Redis/Memcache should be the fastest, they are on par with the File Store EBS. The reason is probably the lack of networking overhead for local file storage.

Another interesting observation is that the FileStore is consistently ~10-20% faster than SolidCache SQLite. It makes sense as SQLite is a layer of abstraction on top of the file system, so it incurs additional overhead. I’m not 100% sure if this metric will hold true for systems under production-like load. But if you want to squeeze out a few more microseconds then the the good ol’ ActiveSupport::Cache::FileStore instead of SQLite could be a better choice.

Please remember that AWS EBS (even gp3) volumes are notoriously slow. When running the benchmark locally on an MBP, I’m observing ~3x better performance for FileStore and SolidCache SQLite. So if you want to maximize the SQLite and cache performance, choosing a VPS provider with high-speed NVMe disks is probably worth it.

While we’re at data stores, I would like to highlight the AWS EFS file system. It’s EBS-equivalent but can be shared between multiple EC2 instances. It’s ~10x more expensive than EBS, but using it instead of PostgreSQL would mean saving money on database instances. It could be an interesting choice for projects using SQLite with multi-server architecture or for leveraging a shared file-based caching layer. I’m currently working on a blog post covering more details on using EFS with Rails. You can follow or subscribe to get notified when it’s live.

Using a custom compressor for Rails cache

Another exciting feature introduced in Rails 8 is support for custom cache compressors. I’ve built the rails-brotli-cache gem around this idea, so it’s awesome to see it upstream. The feature has not made it to the Rails guides yet, but hopefully, this PR will get merged sooner or later. As of now compressor config is described only in ActiveSupport::Cache::Store docs.

I’ve tested a few compression algorithms when working on rails-brotli-cache (benchmark). Choosing “the best one” is a matter of tradeoffs between performance and compression ratio. But zstd-ruby with level: 10 config is a quick & easy choice, offering speed and compression superior to both gzip and brotli.

lib/zstd_compressor.rb

require "zstd-ruby"

module ZSTDCompressor
  def self.deflate(payload)
    ::Zstd.compress(payload, level: 10)
  end

  def self.inflate(payload)
    if payload.start_with?("\x78")
      Zlib.inflate(payload)
    else
      ::Zstd.decompress(payload)
    end
  end
end

config/production.rb

config.cache_store = :solid_cache_store, { compressor: ZSTDCompressor }

Applying this config should improve caching read/write performance by ~30% and compression ratio by ~20%. If you want to use this feature make sure to include:

config.load_defaults "7.1"

in config/application.rb. This change is backward compatible, so you can start using the new algorithm without clearing the current cache contents.

SQLite vs PostgreSQL

In Rails 8 SQLite becomes a first-class citizen. This talk by Stephen Margheim provides an in-depth look at the changes introduced and explains how SQLite’s support and performance improved.

I briefly considered switching Abot’s primary database to SQLite instead of PostgreSQL. I’d love to cut the monthly RDS costs, but I’m not comfortable keeping the business-critical data on the server. “cattle not pets” they said. I’m used to regularly nuking and reprovisioning EC2 instances, so the chances of accidentally wiping production data skyrocket with SQLite.

litestream is an awesome tool for continuously backing up SQLite. But I’d rather not bet the project’s existence on it working seamlessly.

Another disadvantage of SQLite vs. PG is the lack of advanced monitoring. Tools like PgHero, (shameless plug alert!) rails-pg-extras, or pg-locks-monitor provide detailed insights into what’s going under the hood in PostgreSQL.

With SQLite going mainstream in the Rails world, hopefully, open source will soon catch up, and we’ll have more ways to analyze it. I’ve started building rails-sqlite-extras. But I don’t have much SQLite exp, so ideas on how to improve it are welcome.

For now, I’m happy to keep Abot’s solid queue and cache databases on SQLite and primary on PostgreSQL.

Summary

Rails 8 is a decent step forward. It makes things cheaper, faster, more productive. There are some drawbacks, like the Kamal mandatory registry, but I hope it will be sorted out soon.

How to Improve Rails Caching with Brotli Compression

Tue, 12 Sep 2023 08:36:01 +0200

Caching is an effective way to speed up the performance of Rails applications. However, the costs of an in-memory cache database could become significant for larger-scale projects. In this blog post, I’ll describe optimizing the Rails caching mechanism using the Brotli compression algorithm instead of the default Gzip. I’ll also discuss a more advanced technique of using in-memory cache for extreme performance bottlenecks.

Brotli vs Gzip 101

In one of my previous posts, I’ve covered how Rails leverages compression algorithms for the HTTP transport layer. Please check it out for more details on how Gzip and Brotli differ in compression ratios and performance. Here, let’s quickly recap the basics.

You can use Gzip and Brotli using Ruby API wrapping underlying C libraries. To Gzip a sample JSON file and measure the compression rate, run the following code:

require 'json'
require 'zlib'

json = File.read("sample.json")
puts json.size # => 1127380 bytes ~ 1127kb
gzipped = Zlib::Deflate.deflate(json)
puts gzipped.size # => 167155 bytes ~ 167kb

As you can see, a standard Gzip compression on a JSON reduced the size by ~85%.

Let’s now see how to use Brotli. You have to start by installing a Brotli gem:

gem install brotli

Now you can run:

require 'json'
require 'brotli'
json = File.read("sample.json")
puts json.size # => 1127380 bytes ~ 1127kb
brotlied = ::Brotli.deflate(json, quality: 6)
puts brotlied.size # => 145056 bytes ~ 145kb

Brotli is slow with the default quality settings, so 6 is recommended for on-the-fly compression.

Brotli compression is ~13% better than Gzip for this sample JSON. But, according to the sources, improvement can be as high as 25%.

Another advantage of Brotli is the speed of the compression and decompression process. Based on my benchmarks, Brotli can be ~20% faster than Gzip when used for Rails cache. The overhead of the caching layer will probably not be the bottleneck of your Rails app. But, if you’re using caching extensively, then a 20% improvement might translate to a measurable global speed-up.

But better compression could be even more impactful than read/write performance. I’ve discussed how to reduce the costs of in-memory cache databases when caching ActiveRecord queries in my other blog post. Combined with the tips on reducing the size of cache payloads, Brotli compression could lower caching infrastructure costs. Also, more space for cache means less frequent rotation of older entries, translating to better performance.

How to use Brotli for Rails cache?

By default, Rails cache uses the Gzip algorithm for payloads larger than 1kb. But, as we’ve discussed, Brotli offers better compression ratios and speed. You can start using Brotli in your Rails app with the help of the rails-brotli-cache gem that I’ve recently released.

It works as a proxy wrapper for standard cache stores, precompressing the payloads with Brotli instead of Gzip. I’ve measured a 20%-40% performance improvement in Rails.cache depending on the underlying data store. You can check out the benchmarks.

After adding it to your Gemfile, you have to change a single line of config to hook it up:

config/environments/production.rb

config.cache_store = RailsBrotliCache::Store.new(
  ActiveSupport::Cache::RedisCacheStore.new(url: ENV['REDIS_URL'])
)

Check out the gem readme for information on using it with different cache store types.

Also, remember to run Rails.cache.clear after after first enabling it to remove previously gzipped cache entries. But watch out not to wipe your Sidekiq in the process!

Optionally, you can hook up a custom compression algorithm. For example, Google Snappy offers even better performance than Brotli for the cost of worse compression ratios. ZSTD by Facebook is also worth checking out.

Gem uses an API compatibility spec to ensure that it behaves exactly as the underlying data store. I’m currently using it in a few production projects, but please submit a GH issue if you notice any inconsistencies.

The great news is that support for custom cache compression algorithms has recently been merged into the Rails main branch. A new :compressor config option should be available in the upcoming Rails 7.1.

Using and misusing in-memory cache store

I’ve mentioned that rails-brotli-cache offers ~20% speed improvement compared to the other cache stores. But there’s a catch. Let’s consider the following benchmark:

require 'active_support'
require 'active_support/core_ext/hash'
require 'net/http'
require 'rails-brotli-cache'
require 'benchmark'

json_uri = URI("https://raw.githubusercontent.com/pawurb/rails-brotli-cache/main/spec/fixtures/sample.json")
json = Net::HTTP.get(json_uri)

redis_cache = ActiveSupport::Cache::RedisCacheStore.new
brotli_redis_cache = RailsBrotliCache::Store.new(redis_cache)
memcached_cache = ActiveSupport::Cache::MemCacheStore.new
brotli_memcached_cache = RailsBrotliCache::Store.new(memcached_cache)
file_cache = ActiveSupport::Cache::FileStore.new('/tmp')
brotli_file_cache = RailsBrotliCache::Store.new(file_cache)
memory_cache = ActiveSupport::Cache::MemoryStore.new
brotli_memory_cache = RailsBrotliCache::Store.new(memory_cache)

iterations = 100

Benchmark.bm do |x|
  x.report("redis_cache") do
    iterations.times do
      redis_cache.write("test", json)
      redis_cache.read("test")
    end
  end

  x.report("brotli_redis_cache") do
    iterations.times do
      brotli_redis_cache.write("test", json)
      brotli_redis_cache.read("test")
    end
  end

  x.report("memcached_cache") do
    iterations.times do
      memcached_cache.write("test", json)
      memcached_cache.read("test")
    end
  end

  x.report("brotli_memcached_cache") do
    iterations.times do
      brotli_memcached_cache.write("test", json)
      brotli_memcached_cache.read("test")
    end
  end

  x.report("file_cache") do
    iterations.times do
      file_cache.write("test", json)
      file_cache.read("test")
    end
  end

  x.report("brotli_file_cache") do
    iterations.times do
      brotli_file_cache.write("test", json)
      brotli_file_cache.read("test")
    end
  end

  x.report("memory_cache") do
    iterations.times do
      memory_cache.write("test", json)
      memory_cache.read("test")
    end
  end

  x.report("brotli_memory_cache") do
    iterations.times do
      brotli_memory_cache.write("test", json)
      brotli_memory_cache.read("test")
    end
  end
end

Check out the gem repo for a complete benchmark code

You should get similar results:

                       user     system   total    real
redis_cache            1.770976 0.040232 1.811208 (2.587884)
brotli_redis_cache     1.387118 0.077257 1.464375 (2.137552)
memcached_cache        1.787665 0.058871 1.846536 (2.534051)
brotli_memcached_cache 1.368171 0.088934 1.457105 (2.043203)
file_cache             1.716816 0.055140 1.771956 (1.772132)
brotli_file_cache      1.319149 0.068127 1.387276 (1.387309)
memory_cache           0.001370 0.000117 0.001487 (0.001480)
brotli_memory_cache    1.330853 0.043904 1.374757 (1.374784)

Here’s an ASCII chart for easier comprehension:

redis_cache            |████████████████████
brotli_redis_cache     |████████████████

memcached_cache        |████████████████████
brotli_memcached_cache |████████████████

file_cache             |████████████████
brotli_file_cache      |███████████████

memory_cache           |
brotli_memory_cache    |███████████

As you can see, rails-brotli-cache proxy improves the performance for all the cache storage types apart from ActiveSupport::Cache::MemoryStore. And this storage type is ~99% faster than all the other types. What’s going on?

Nested cache layers

ActiveSupport::Cache::MemoryStore is unique because compared to other cache store types, it does not compress cached entries. Also, it keeps cached entries directly in the process RAM, so there’s no serialization, networking, or filesystem IO overhead. If we run the benchmark with in-memory compression enabled, we’ll get the following results:

memory_cache = ActiveSupport::Cache::MemoryStore.new(compress: true)

memory_cache           |█████████████████
brotli_memory_cache    |███████████

As you can see, compression causes significant overhead for all the cache store types. For some extreme cases, you can use this order of magnitude better performance of uncompressed in-memory cache-store. The tradeoff will be higher RAM usage of your Ruby processes, but 99% performance improvement could be worth it.

To do it, you can wrap your standard Rails cache into a custom in-memory store like this:

config/application.rb

$memory_cache = ActiveSupport::Cache::MemoryStore.new

and now in your bottleneck endpoint:

app/controller/users_controller.rb

class ProductsController < ApplicationController

# ...

def index
  cache_key = "cached_products-#{params.hash}"
  cached_products = $memory_cache.fetch(
    cache_key,
    expires_in: 30.seconds, race_condition_ttl: 5.seconds
  ) do
    Rails.cache.fetch(cache_key, 5.minutes) do
      Product::FetchIndex.call(params)
    end
  end

  render json: cached_products
end

In the above example, we’re using two layers of caching. The outer layer using $memory_store in-memory cache is set to expire every 30 seconds. It means that our underlying standard cache store will be called significantly less often. As discussed, the performance of the caching layer for most of the requests will be ~99% better. For endpoints under heavy load, configuring race_condition_ttl will also reduce the number of redundant cache refresh calls.

This example might seem a bit convoluted. But for bottleneck endpoints that serve identical data to multiple clients, similar hacks could measurably reduce the load on your Redis/Memcache database and improve performance. But remember that it’s easy to misuse this technique and bloat the app’s RAM usage.

Summary

Replacing a standard Gzip compression with rails-brotli-cache gem is a relatively simple change that might result in a global speed-up for your Rails app. Another benefit is that it could help you reduce the costs of the in-memory cache database thanks to better compression. I invite you to give it a try. Feedback and PRs on how to improve the gem are welcome.

Five Easy to Miss Performance Fixes for Rails Apps

Tue, 09 May 2023 05:36:01 +0200

Improving the performance of a Rails application can be a challenging and time-consuming task. However, there are some config tweaks that are often overlooked but can make a significant difference in response times. In this tutorial, I will focus on a few “quick & easy” fixes that can have an immediate impact on the speed of your Rails app.

Eliminate request queue time

Request queue time means that your web servers don’t have enough capacity to process the incoming traffic. Unless you’re using a PAAS platform like Heroku, you have to add an extra NGINX header to enable request queuing data in the logs:

proxy_set_header X-Request-Start "t=${msec}";

This config will enable any popular APM monitoring tools to report the current queue time. Without it, it’s impossible to know the real backend response time as experienced by your users.

Correctly configured NewRelic APM should display Request Queuing metric

The presence of queue time is both good and bad news. Your consumers experience longer response times, but resolving it by spinning up more server instances is usually possible. Before throwing money at a dozen new Heroku dynos, double-check if you cannot extract more throughput without increasing the cost.

These Heroku docs recommend values of WEB_CONCURRENCY and RAILS_MAX_THREADS for different dyno types. It’s worth noting the Performance-M dynos offer the worst cost/metrics and should usually be replaced by a single Performance-L or a fleet of Standard-2X.

I usually try to squeeze enough Puma workers so that RAM usage never spikes above 80%. A relatively simple way to decrease memory usage and prevent leaks is to use Jemalloc instead of the default memory allocator. I’ve seen memory usage drop by 15-20% after adding Jemalloc. It usually allowed us to safely add one more Puma worker for the same server/dyno type and increase the app’s throughput. You can check out my other blog post for more info on how to use Jemalloc in Rails apps and other tips on reducing memory usage.

Enable cache and Redis connection pool

Unless you’re on the newest Rails, your app’s caching layer may be misconfigured. Production Rails apps often use Redis or Memcache as their in-memory cache backend. But, the default config of the cache client is single-threaded. A default support for connection pool was added around a year ago. So, if you’re using Rails < 6.1 with a Puma web server, multiple Puma threads compete for a single cache client connection.

You can enable a connection pool for your caching client with similar config options:

config/production.rb

config.cache_store = :mem_cache_store, "cache.example.com",
                     pool: { size: 5, timeout: 5 }

If your app uses Redis directly, it could have the same problem. It’s a popular pattern to expose Redis client via a global variable:

$redis = Redis.new(url: ENV.fetch("REDIS_URL"))

value = $redis.get("key-name")

But it means any interaction with it will be throttled in multithreaded processes like Puma or Sidekiq. Redis usually responds in ~1ms, but if you’re using it extensively, dozens of blocked calls could add up to a measurable overhead.

You can resolve it by leveraging a connection-pool gem:

$redis_pool = ConnectionPool.new(size: ENV.fetch("RAILS_MAX_THREADS", 5)) do
  Redis.new(url: ENV.fetch("REDIS_URL"))
end

value = $redis_pool.with do |conn|
  conn.get("key-name")
end

Fine-tune database connections pool

Balancing the number of web servers and background worker threads with the database pool and max connections can be challenging. pool config from config/database.yml file determines how many database connections can be opened by a single Ruby process.

If you’re using a multithreaded process like Puma or Sidekiq, you need to make sure that the value of pool is at least equal to the maximum number of threads. Otherwise, your app could start raising ActiveRecord::ConnectionTimeoutError if it cannot establish a database connection for the specified timeout. The sum of possible connections should not be larger than the max_connections PostgreSQL setting. But you cannot set max_connection to any arbitrary value. Multiple concurrent connections will increase the load on a database, so its specs must be adjusted accordingly.

AWS RDS offers powerful insights and customizable CloudWatch alerts for PostgreSQL database.

It’s possible to oversee pool misconfiguration. For example, threads could be waiting for database access for a period shorter than timeout, adding performance overhead but never raising the error.

You must be extra careful when using a load_async API introduced in Rails 7. This is because it schedules threads within threads and exhausts more database connections. You can read about it in more detail in my other blog post.

Customize PostgreSQL config

Depending on what PostgreSQL provider your app uses, you might be able to tweak the database config. More extensive control is another reason why I recommend migrating the Heroku database to RDS.

If your PostgreSQL is handling larger datasets, tweaking the default config will likely increase SQL performance. A few examples:

random_page_cost is set to 4.0 by default. It determines how likely a query planner is to use an index scan instead of a sequential scan. The default value of 4.0 originates from IO read speed of HDD disks. It is no longer relevant when databases use much faster SSDs for storage. Setting this value between 1.1-2.0 will make better use of database indexes and reduce CPU-intensive sequential scans.

work_mem determines how much RAM is available per active connection. The default value is 4096kb. Depending on your app’s usage patterns, this setting might throttle SQL queries doing more complex in-memory sorting and hash table operations. This value has to be tweaked carefully because it could cause out-of-memory issues for a database. But, ensuring that each connection has enough RAM will likely increase the performance of more complex queries.

shared_buffers and effective_cache_size settings determine how much database RAM is delegated for caching. Performant databases should read ~99% of data from the in-memory cache. You can use rails-pg-extras cache_hit to inspect your app’s database cache usage. For some cases increasing the default value is likely to result in a speedup for the database layer.

Optimize HTTP layer config

All the previous tips are related to backend layer performance. But, a typical web app issues dozens of requests on initial load. And only a few are backend-related, i.e., website HTML, API calls, etc. The majority of requests are static assets, JavaScript libraries, and images. Therefore, optimizing the frontend-related requests can have a much greater effect on the perceivable performance than fine-tuning the backend.

Check out my other blog post for more detailed tips on optimizing frontend performance. But, since I’ve promised “quick and easy” fixes, let’s cover two potentially most impactful frontend config tweaks.

Client-side caching

Correctly configuring client-side caching could be the most critical frontend optimization. There’s no better way to speed up the HTTP request than not to trigger it. But I’ve seen it misconfigured in multiple production apps. Rails have a great mechanism to leverage client-side caching, i.e., MD5 digest. In the production environment, the application.js file becomes application-523bf7...95c125.js. The random suffix is generated based on the file contents, so it is guaranteed to change if the file changes. You must add the correct cache-control header to make sure that once downloaded, the file will persist in the browser cache:

cache-control: public, max-age=31536000, immutable

The immutable parameter ensures that the cache is not cleared when the user explicitly refreshes the website on the Chrome browser.

You have to enable it in your Rails production config:

config/production.rb

config.static_cache_control = 'public, max-age=31536000, immutable'
config.public_file_server.headers = {
  'Cache-Control' => 'public, max-age=31536000, immutable',
  'Expires' => 1.year.from_now.to_formatted_s(:rfc822)
}

Or if you’re using NGINX as a reverse proxy, you can use the following directive:

location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
  try_files $uri =404;
}

I’ve seen apps using Etag and Last-Modified headers instead of Cache-Control. Etag is also generated based on the file contents, but the client has to talk to the server to confirm that the cached version is still correct. It means that on every page visit, the browser has to issue a request to validate its cache contents and wait for 304 Not Modified response. This completely unnecessary network roundtrip can be avoided by adding a Cache-Control header.

Use Cloudflare CDN

Using CloudFlare for your DNS together with proxying enabled could be the simplest way to get most of your frontend-related config in order. It will be especially impactful if you’re using Heroku, which still does not support HTTP2 or even native Gzip compression… (╯°□°)╯︵ ┻━┻

Client-side caching with Cloudflare proxy will result in your static assets getting cached in CDN edge locations close to your end users. Subsequent requests for the same assets will not be triggered because data is now cached in the browser.

Please remember to use Respect existing headers for Browse Cache TLL setting to regain more fine-tuned control and avoid stale cache issues.

In addition to global CDN CloudFlare will enable to following benefits for your app:

automatic gzip/brotli compression
HTTP2 support
DDOS protection
Signed Exchanges SXGs support that can benefit Largest Contentful Paint (LCP) metric and SEO (available only for paid plans)

And many features more.

You can use Page Speed insights and WebPageTest to get a quick overview of your app’s fronted performance.

Summary

Optimizing the mentioned configs is a great starting point for in-house performance tuning. They are likely to globally impact the performance metrics, so the development time spent tweaking them will probably yield measurable benefits.

How to Freeze ETH and ERC20 Tokens using Smart Contract

Wed, 19 Apr 2023 00:36:01 +0200

I’m still the kind of person that buys $500 worth of Dogecoin, and one day later, panic sells with a 30% loss. That’s why, I’ve developed Ethereum smart contracts that make speculating on cryptocurrencies less stressful. Locker smart contracts allow me to freeze crypto assets and only release them when enough time has passed or the price has reached a predefined value. This approach sacrifices liquidity for peace of mind, and for me, that’s a perfect tradeoff! In this article, I’ll describe this project and the risks associated with using it or basically any Smart Contract.

Disclaimer: The information provided in this blog post is for educational purposes only and should not be treated as investment advice.

Decentralized trust

The crypto scene is ripe with scams and exploits siphoning billions in user funds. Despite that, I kind of see it as the only tech that can be “trusted”. Ethereum Smart Contracts are literally the only existing technology guaranteed to work as programmed.

Of all the popular smart contract technologies, Ethereum is the only one that enables a standard user to run a full node. On the other hand, all the “Ethereum killers” network nodes are either centralized or require processing power and dev ops expertise accessible only to well-funded entities. As a result, the network consensus is governed by a few centralized actors rather than the decentralized community. You can check this tutorial for more info on how to run your own Ethereum full node.

Obviously, “I’m in it for the technology”. I’ve become attracted to crypto as a tech rather then casino after getting all my bank funds repeatedly locked. It is enough to send one transfer to Revolut, too many to trigger a complete lockdown of all my accounts and credit cards. “Risky transaction…“ they said. Getting my funds unfrozen usually takes ~30min on a bank support line. But the idea that all my finances can be locked at a whim of a single centralized entity is disturbing…

You’ve probably heard about Canadian anti-vax trucker supporters getting their accounts frozen without any judicial order. In Poland, we’ve also had our taste of a digital prison. People protesting against anti-abortion laws got their bank accounts blocked for “breaking the pandemic sanitary regulations”. Or the case of Ukrainian refugees seeing their EUR account balances automatically converted to UAH with a special exchange rate spread “because war”.

Diversifying a part of funds in a layer that’s unreachable by a state-level 3rd party seems like a reasonable idea. Since this revelation, I’ve started seeing the crypto price ups and downs as a “tax for safety” rather than a chance for speculation.

So much for the digression. Let’s move on to the risks of using the Locker or basically any smart contract.

Can you trust Smart Contracts?

Different layers of trust could be broken and cause the loss of tokens you deposit into smart contracts.

Bugs and deliberate scams

To start with, the contract author could be a scammer or an clumsy blockchain dev. So the Locker source code could contain a sneaky loophole or bug causing the loss of your funds. The open-source nature of Ethereum Smart Contracts is the best remedy for these risks.

Before you deploy the contract or interact with an already live instance, you can always analyze the source code. But currently, it requires a significant dose of expertise. Locker smart contracts are relatively simple, maxing out at 200 LOC with minimal external dependencies. But, most Defi projects are endless blobs of code that are impossible to analyze single-handedly. A potential revolution in the safety of Smart Contracts could be the advent of AI. ChatGPT seems to be proficient in analyzing security issues of Ethereum smart contracts. An AI-based service listing potential risks of any smart contract interaction (maybe even integrated into your wallet!) could be just around the corner.

The contract’s external dependencies and logic introduce another risk factor. In the case of Locker, it “trusts” the provided ChainLink oracles to report the correct price of the target token. The user selects an oracle address himself when configuring the deposit. The only risk is that oracles could be abandoned and not update the price correctly. In that case, your tokens would be released only after the lockup period.

In the case of more complex smart contracts, external risk factors are often significant. For example, the creator of an ERC20 token could grant himself the power to print unlimited units and tank the price at your cost. Given the complexity of Defi smart contracts spotting similar risks is non-trivial. Hopefully, AI will be able to help standard users make more sense of these issues.

Frontend interface

Another layer of trust is how one can interact with the contract instance. Locker does not offer any front-end UI. You have to interact with it directly on Etherscan or use programmatic API. Interacting with any Defi project featuring custom frontend is a risk factor. Exploits targeting frontend layer of the smart contracts stack could alter where your funds are sent. Or malicious browser extension can change the frontend code of an otherwise trustworthy web3 domain.

The best way to reduce the risk of interacting with any smart contracts is to use minimum ERC20 approval limits. Metamask has recently improved its UX by allowing users to input approval limits manually. Before that, the approval limits were implicitly unlimited, allowing attackers to withdraw all your assets.

Metamask UI for custom ERC20 approval limit

Also, using a hardware wallet like Ledger or Trezor can prevent a range of crypto exploits.

Government censorship

A government could, in theory, censor any smart contract address. So far, the most famous case of government sanctioning a piece of autonomous software was Tornado Cash. Apparently, you can also go to jail for writing open-source code.

The fight against decentralized finance may intensify. For example, the EU is currently brewing new restrictions for Smart Contracts. But, despite sanctions from the US government, the Tornado Cash smart contracts are still regularly used. It shows that cryptocurrencies excel at their core value proposition of being uncensorable even by government-level actors.

All the centralized elements of Tornado Cash like frontend interface, domain, and GitHub repos were succesfully taken down. But it’s still possible to access Tornado Cash immutable smart contracts using proprietary Ethereum full node or censorship-resistant relay providers.

User error

Any smart contract interaction is risky. There’s no edit/undo button for incorrect transactions. Ask the guy who burned 500k USD by incorrectly unwrapping WETH. If you misuse Smart Contract and lose funds, even Metamask Twitter Support will be unable to help you.

Now that we’ve briefly covered the risks, let’s move on to the Locker smart contracts.

Locker smart contracts

There are four different flavours: Locker, LockerETH, LockerPriv, and LockerETHPriv.

Locker

Locker can be used to freeze any ERC20 token and is accessible by any account. Your funds will be deposited into the same contract address as other users. But, each user can only withdraw his tokens. The benefit is that you don’t have to deploy the contract instance yourself. ETH can be held by this contract only in its ERC20 format, i.e., as WETH. To use price conditions for release, you must provide a correct ChainLink price oracle address.

[Warning] Do not transfer ERC20 tokens directly to this contract instance or they will be lost! You have to use a dedicated deposit method. Also, do not use this contract for storing rebasing tokens like stETH or rETH. Stored token balance is determined once when depositing the token. It means that rebased reward will get stuck in the contract forever.

LockerETH

LockerETH works the same as Locker but only for standard ETH instead of ERC20 tokens. It uses a predefined ChainLink ETH/USD price oracle. It’s also publicly accessible.

LockerPriv

LockerPriv works as your private vault for ERC20 tokens. Only the deployer account can interact and deposit funds into it. The downside is that you have to pay the costs of releasing it. With Mainnet gas prices at 20 gwei and the price of ETH hovering around $2000 it costs ~$100. Alternatively, you can use one of the L2 layers to reduce the deployment cost. For example, on Arbitrum L2 it costs ~$5 to deploy an instance of this Smart Contract.

LockerETHPriv

As you can probably guess LockerETHPriv, is a private vault for storing a standard ETH. Just like in the case of LockerPriv you have to deploy it yourself.

Summary

I hope the post has helped highlight the risks of using Smart Contracts. Please remember that crypto and Defi is risky, and you can easily lose all your funds.

But cryptocurrencies are here to stay. UX and general appeal is only about to improve. The worst-case scenario is that hostile governments might slow adoption for a few years until there’s a shift in power. So safely stashing your coins could be a strategy to wait out turbulent times.

How to Find, Debug and Fix N+1 Queries in Rails

Tue, 07 Mar 2023 04:09:06 +0100

Fixing N+1 issues is often the lowest-hanging fruit in optimizing a Rails app performance. However, for non-trivial cases choosing a correct fix could be challenging. Incorrectly applied eager loading does not work or even worsens response times. In this blog post, I describe tools and techniques I use to simplify resolving N+1 issues.

How to simulate N+1 issues in development

I doubt the Rails blogosphere needs yet another introduction to N+1 queries. You can check out my previous post for a quick recap.

Instead, let’s discuss how to establish a repeatable routine for spotting N+1 issues before they start manifesting in production. It’s common for developers to work with a minimal local data set. Unfortunately, working with a database resembling production is usually not possible. But seeding local data for your test user to mimic production sizes could be a perfect compromise.

Hundreds of test objects will not be enough to simulate slow SQL queries. PostgreSQL usually needs tens of thousands of table rows for any SQL-layer slowdown to manifest. But N+1 query issues are not related to absolute collection sizes but to how you use and misuse ActiveRecord ORM. A dozen objects are enough to trigger N+1 issues and make them detectable during development.

A simple way to quickly populate your local data is to use a FactoryBot gem. You may already have used it in your project but did not consider leveraging it to seed development env. To do it you have to include the gem in development group of your Gemfile. Now in the Rails console:

require 'factory_bot'

100.times do
  FactoryBot.create(:post, user: your_test_user)
end

#...

Of course, the exact implementation will be unique for each project. But leveraging existing factories should simplify the process compared to writing seed scripts from scratch.

Another benefit of working with a larger local collection is that you’ll spot places likely to benefit from pagination. Before endless lists, bring your production servers to a crawl…

How to analyze and debug local N+1 issues

Now that you have a decent local dataset, you can start digging deeper. bullet gem is a popular tools for reporting N+1 issues. However, its log output is a bit noisy or even illegible for larger projects. I’ve also seen it report many false positives so extracting actionable data it could be challenging. Instead, I usually default to the good ol’ rack-mini-profiler gem:

rack-mini-profiler reporting the number of SQL queries

The popup window shows the number of SQL queries executed per request. It even works with XHR requests. So, if you’re using a SPA framework, you can check quickly how many queries are triggered by each API endpoint.

Another great feature is that you can see the exact line of code that triggered each query:

For many more straightforward cases, this data is enough to track the missing eager loading and validate the fix. But it’s normal for legacy projects to trigger thousands of queries per view. If that is the case making sense of rack-mini-profiler endless backtraces data could be overwhelming. That why I’ve recently developed a way to simplify this process.

After expanding the traces data, click CMD+A and CMD+C to copy it into the clipboard. Now create a new empty text file and paste clipboard contents. I recommend using vim because modern text editors might not handle larger clipboard sizes. Now you can run the following bash script:

sort traces.txt | uniq -c | sort -bgr > output.txt

It groups and counts the unique lines, and pipes output into a new text file. Now on top of this file, you can see which kinds of queries and method execution hits were repeated most often:

 ...
 119 Reader
 118 Executing action: home
 101 app/controllers/web/static_pages_controller.rb:7:in `home'
 101 SELECT "teams".* FROM "teams" WHERE "teams"."id" = $1 LIMIT $2;
 100 app/controllers/web/static_pages_controller.rb:7:in `map'
 ...

It’s usually enough data to spot precisely where the worse N+1 issues originate from and to validate if the fix resolved the problem.

Use rails-pg-extras to dissect N+1 queries

As you can see, the rack-mini-profiler works for many standard scenarios. However, it’s sometimes a lot of work to simulate certain edge cases in the app’s UI. Also, the workflow of manually copying, parsing, and analyzing log outputs is far from ideal. So, I’ve recently released a small tool that helps me iterate on N+1 issues faster.

My rails-pg-extras gem has been around for a while. It includes an array of helper methods for analyzing the internals of your PostgreSQL database. measure_queries method is the newest addition to the lib’s API. It leverages ActiveSupport instrumentation to display queries executed by running any provided Ruby snippet:

RailsPgExtras.measure_queries { User.limit(10).map(&:team) }

{:count=>11,
 :queries=>
  {"SELECT \"users\".* FROM \"users\" LIMIT $1"=>
    {:count=>1,
     :total_duration=>1.9,
     :min_duration=>1.9,
     :max_duration=>1.9,
     :avg_duration=>1.9},
   "SELECT \"teams\".* FROM \"teams\" WHERE \"teams\".\"id\" = $1 LIMIT $2"=>
    {:count=>10,
     :total_duration=>0.94,
     :min_duration=>0.62,
     :max_duration=>1.37,
     :avg_duration=>0.94}},
 :total_duration=>13.35,
 :sql_duration=>11.34}

In theory, you can extract the same data by piping ActiveRecord logging to STDOUT:

ActiveRecord::Base.logger = Logger.new(STDOUT)

Produces:

D, [2023-03-01T13:57:42.815016 #19045] DEBUG -- :   User Load (1.6ms)  SELECT "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT $1  [["LIMIT", 20]]
D, [2023-03-01T13:57:42.817497 #19045] DEBUG -- :   Team Load (2.1ms)  SELECT "teams".* FROM "teams" WHERE "teams"."id" = $1 LIMIT $2  [["id", "[FILTERED]"], ["LIMIT", 1]]
D, [2023-03-01T13:57:42.819068 #19045] DEBUG -- :   Team Load (1.2ms)  SELECT "teams".* FROM "teams" WHERE "teams"."id" = $1 LIMIT $2  [["id", "[FILTERED]"], ["LIMIT", 1]]
(.....N+1 more lines.....)
D, [2023-03-01T13:57:42.843380 #19045] DEBUG -- :   Team Load (1.0ms)  SELECT "teams".* FROM "teams" WHERE "teams"."id" = $1 LIMIT $2  [["id", "[FILTERED]"], ["LIMIT", 1]]
D, [2023-03-01T13:57:42.844977 #19045] DEBUG -- :   Team Load (1.4ms)  SELECT "teams".* FROM "teams" WHERE "teams"."id" = $1 LIMIT $2  [["id", "[FILTERED]"], ["LIMIT", 1]]

But it’s arguably less readable. And for more complex cases, it is likely to produce an endless log stream instead of an easy-to-comprehend hash aggregating all the necessary data.

Optionally, with the help of marginalia gem, you can add backtraces info to standard ActiveRecord logs output. As an effect it will be included in the measured queries data:

Marginalia gem appends origin line numbers to measured query logs

You have to configure Marginalia to enable this feature:

config/development.rb

Marginalia::Comment.components = [:line]

I’m using the measure_queries helper method for my ongoing Rails performance audits. It has significantly improved my workflow allowing for faster iteration on N+1 related fixes. I no longer have to use a rack-mini-profiler UI. Instead, I can now apply the change, type reload! (aliased to re) straight in the Rails console and quickly measure if a refactored method is faster and triggers fewer queries. Being able to debug on the lower layer of models/services instead of HTTP endpoints is a huge productivity boost.

Since this API is relatively new I’m open to feedback on improving it.

Use specs to prevent N+1 queries

Another way to keep the N+1 problem under control is to leverage your test suite. You can use the same measure_queries to constraint how many queries any Ruby code snippet is allowed to trigger. Arguably the simplest way to use it is on a per-endpoint level with controller specs:

describe UsersController do
  # ...

  describe "index" do
    it "does not exceed queries limit" do
      queries = RailsPgExtras.measure_queries do
        get :index
      end
      expect(queries.fetch(:count)).to be < 5
    end
  end
end

The above spec will fail if the number of queries exceeds a predefined threshold. Alternatively, you can check out the n_plus_one_control gem for more complex rspec matchers related to N+1 queries.

Summary

With adequate tooling, it’s possible to spot and resolve N+1 issues before they reach production. I hope that some of the above tips will help you improve your workflow when fixing these problems.

How to Subscribe to YouTube Channels Without an Account

Thu, 16 Feb 2023 08:09:06 +0100

I’m extremely cautious with YouTube. I’ve lost countless hours because of their flawless recommendation algorithms. In one of my previous posts, I describe how to “cripple” YouTube recommendations UI and start using it more deliberately. I also prefer to use YouTube without logging in, but it makes following my favorite channels difficult. So in this tutorial, I describe how to over-engineer your way to subscribing to YouTube channels without having an account.

How to find an RSS feed of a YouTube channel?

Every YouTube channel has an undocumented RSS feed representing its content. But it’s not available in the UI. Instead, you have to dig into the HTML source code to extract it:

In the channel "Videos" web page source code, search for RSS to find the DOM element with the feed address

Or, even simpler, you can run this JS code in the console to extract an RSS address:

document.querySelector('link[rel="alternate"][type="application/rss+xml"]').href.match(/channel_id=([^&]+)/)[1];

Remember to search "Videos" and not "Home" tab of a channel for the RSS feed

Once you have RSS feeds of your favorite channels, you can use any RSS app to monitor them. I like to use Slack for this purpose. An official Slack RSS app sends a channel message when there’s a new RSS item.

Alternatively, if you’re on a paid Zapier plan, you can batch your RSS notifications with their Delay Zap Action to arrive at a specific time. Or, if you prefer self-hosted solutions, you can check out a Huginn Ruby gem or ActivePieces for similar functionality.

YouTube channels are just an example. You can use this technique for any source exposed via an RSS feed. For me, RSS is a superior way to consume social media. No ads, no click baits, just hand-picked content delivered straight to your Slack channel. At a time of your and not user engagement algorithm choice.

Custom Zapier notifications in Slack

Summary

Consuming most social media via RSS feeds allowed me to reduce my addiction to garbage content. Or at least I can now deliberately choose garbage I like without going on a binge. Most social media platforms prioritize time spent scrolling instead of quality. So similar overengineered tricks could be a way to break their “optimizations” and defend your time and focus.

Easy to Overlook Way to Break Eager Loading in Rails Apps

Tue, 10 Jan 2023 06:09:06 +0100

In theory, configuring eager loading to avoid N+1 issues is straightforward. Chaining includes method is usually enough to ensure that all the relations data is fetched efficiently. However, this rule breaks for some easy-to-overlook edge cases. In this blog post, I’ll describe how to eager load ActiveRecord relations using custom SQL ORDER BY sorting.

How to use eager loading with ORDER BY in SQL?

Based on my experience conducting Rails performance audits, N+1 issues are a primary cause of sub-optimal response times in Ruby on Rails apps. ActiveRecord makes it just too easy to sneak in an N+1 bug in production. It’s easy to miss it in development because you usually work with small datasets.

Let’s analyze a sample scenario of displaying the products of a user:

app/models/user.rb

class User < ApplicationRecord
  has_many :products
end

app/models/product.rb

class Product < ApplicationRecord
  belongs_to :user

  scope :by_rating, -> { order(rating: :desc) }
end

app/controllers/users_controller.rb

class UsersController < ApplicationController
  def index
    @users = User.limit(50).includes(:products)
  end
end

In theory, this implementation should correctly eager-load all the product objects and prevent N+1 queries.

But let’s consider the following view layer implementation:

app/views/users/index.html.erb

<div>
  <% @users.each do |user| %>
    <p> <%= user.id %> products </p>
    <ul>
      <% user.products.by_rating.each do |product| %>
        <li><%= product.name %></li>
      <% end %>
    </ul>
  <% end %>
</div>

The addition of by_rating scope effectively breaks the eager loading. Adding a where call would have the same effect. It is caused by chaining methods that alter the relation SQL and invalidate the previously eager loaded collection. It’s even worse than not using eager loading at all. includes still triggers additional queries, but results are discarded.

A naive approach to avoiding N+1 issues in similar situations could be to work with methods that do not alter the relation SQL. It means that instead of adding by_rating scope, you’d need to use a method that does the sorting in Ruby:

app/views/products/index.html.erb

<% user.products.sort_by { |pr| -pr.rating }.each do |product| %>
  <li><%= product.name %></li>
<% end %>

Similarly, instead of where, you could use the select method. It filters collection in Ruby instead of an SQL WHERE clause.

Using custom relation to prevent N+1 queries

However, there are downsides to using Ruby instead of SQL to transform relation objects. For example, sorting in Ruby can be slower than SQL ORDER BY or even impossible for larger data sizes. And using select to filter the collection means that you’ll discard already initialized ActiveRecord objects, so memory is wasted.

A better way to work with relations that need their SQL customized is to use a dedicated relation method. Let’s see it in action:

class User < ApplicationRecord
  has_many :products
  has_many :products_by_rating, -> { by_rating }, class_name: 'Product'
end

app/controllers/users_controller.rb

class UsersController < ApplicationController
  def index
    @users = User.limit(50).includes(:products_by_rating)
  end
end

app/views/products/index.html.erb

<% user.products_by_rating.each do |product| %>
  <li><%= product.name %></li>
<% end %>

This approach eliminates the additional N+1 queries while preserving custom order without a need for sorting in Ruby.

For non-trivial views, it could be challenging to prevent N+1 issues from emerging accidentally. For example, even custom relations could still trigger N+1 queries if their SQL is further customized. One way to avoid it could be to explicitly call to_a on relations collections before using them. As an effect, ActiveRecord::Relation is transformed into an Array of objects, making it impossible to chain SQL calls.

user.products.to_a.by_rating

# raises => undefined method `by_rating' for Array (NoMethodError)

But it’s arguably not the cleanest solution.

Unfortunatelly, even using the recently added strict_loading on a relation would not detect similar mistakes:

app/models/user.rb

class User < ApplicationRecord
  has_many :products, strict_loading: true
end

User.last(2).map(&:products).map(&:to_a)

# raises => ActiveRecord::StrictLoadingViolationError

User.last(2).map(&:products).map(&:by_rating).map(&:to_a)

# loads the Products but triggers N+1 queries

Summary

You should continuously monitor the number of queries executed by your application. I always recommend using rack-mini-profiler and regularly inspecting SQL queries triggered by each view. This 10-year-old Railscast is still up to date, so the tool did stand the test of time. Getting rid of sneaky N+1 issues could be the lowest-hanging fruit in optimizing your Rails app’s performance.

How to Monitor and Fix PostgreSQL Database Locks in Rails

Tue, 20 Dec 2022 09:09:06 +0100

PostgreSQL database locks usually work seamlessly until they don’t. Before your Rails app dataset and traffic reach a certain scale, you’re unlikely to face any locks-related issues. But if your app suddenly slows down to a crawl, deadlocks likely are to blame. In this blog post, I’ll describe how to monitor database locks and propose best practices to prevent them from causing issues.

PostgreSQL database locks 101

Locks in PostgreSQL are a mechanism for ensuring data consistency in multithreaded environments. This blog post is not trying to be a comprehensive introduction to how locks and related MVVC (Multi-Version Concurrency Control) system works in PG databases. Instead, I’ll focus on the basics to help us understand how locks affect Ruby on Rails apps’ performance and stability.

It’s important to understand that every single write to the database acquires a lock. Well-behaved databases usually commit changes in a few ms, so observing related locks is not straightforward. As a workaround, you can simulate a long-lasting lock by running a similar code in the Rails console:

user = User.last

User.transaction do
  user.update(email: "email-#{SecureRandom.hex(2)}@example.com")
  sleep 25
end

The new column value has to differ from the current one for locks to be acquired.

Now in a separate Rails console process run the locks method from rails-pg-extras gem:

RailsPgExtras.locks(in_format: :hash)

# [
#   {
#     "pid": 64,
#     "relname": "users_pkey",
#     "transactionid": null,
#     "granted": true,
#     "mode": "RowExclusiveLock",
#     "query_snippet": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "age": "PT0.954817S",
#     "application": "bin/rails"
#   },
#   {
#     "pid": 64,
#     "relname": "users",
#     "transactionid": null,
#     "granted": true,
#     "mode": "RowExclusiveLock",
#     "query_snippet": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "age": "PT0.954817S",
#     "application": "bin/rails"
#   },
#   {
#     "pid": 64,
#     "relname": "index_users_on_email",
#     "transactionid": null,
#     "granted": true,
#     "mode": "RowExclusiveLock",
#     "query_snippet": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "age": "PT0.954817S",
#     "application": "bin/rails"
#   },
#   {
#     "pid": 64,
#     "relname": "index_users_on_api_token",
#     "transactionid": null,
#     "granted": true,
#     "mode": "RowExclusiveLock",
#     "query_snippet": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "age": "PT0.954817S",
#     "application": "bin/rails"
#   },
# ...
# ]

As you can see, even a straightforward single-column update operation acquires an array of RowExclusiveLock locks on a corresponding table and all the indexes. Usually, this process works seamlessly behind the scenes. A lock affecting a single row is not critical (apart from slowing down a single request/job) as long as it’s not blocking other queries.

But let’s see what happens when we try to update the same row concurrently.

In the first Rails console process run:

user = User.last

User.transaction do
  user.update(email: "email@example.com")
  sleep 25
end

Then in the second one:

User.last.update(email: "email-#{SecureRandom.hex(2)}@example.com")

and now, in the third Rails console process, we can investigate the collision of concurrent update operations:

RailsPgExtras.blocking(in_format: :hash)

# [
#   {
#     "blocked_pid": 64,
#     "blocking_statement": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "blocking_duration": "PT20.450116S",
#     "blocking_pid": 152,
#     "blocked_statement": "UPDATE \"users\" SET \"email\" = $1 WHERE \"users\".\"id\" = $2",
#     "blocked_duration": "PT8.145238S"
#   }
# ]

As you can see, the acquired lock prevents the second SQL statement from finishing. It’s reported by blocking method from rails-pg-extras. In practice, a web server request trying to execute this SQL statement would be stuck until the first lock is released. This is how misbehaving locks can kill the performance of your application or even cause downtime by exhausting available web server connections.

Monitoring PostgreSQL locks in production

You’re unlikely to sprinkle sleep all over your codebase to simplify investigating database locks. Here’s a sample implementation of a Sidekiq job that can help you monitor long-lasting locks and blocked SQL statements in production:

config/initializers/pg_monitoring.rb

LocksMonitoringJob.perform if ENV["PG_MONITOR_LOCKS"] == "true"

app/jobs/locks_monitoring_job.rb

class LocksMonitoringJob
  include Sidekiq::Worker
  sidekiq_options retry: false

  PG_MIN_LOCK_DURATION_MS = ENV.fetch("PG_MIN_LOCK_DURATION_MS") { 200 }.to_f
  PG_MONITORING_INTERVAL_SECONDS = ENV.fetch("PG_MONITORING_INTERVAL_SECONDS") { 5 }.to_i
  SLACK_WEBHOOK_URL = ENV.fetch("SLACK_WEBHOOK_URL")

  def perform
    locks = RailsPgExtras.locks(in_format: :hash).select do |lock|
      (ActiveSupport::Duration.parse(block.fetch("age")).to_f * 1000) > PG_MIN_LOCK_DURATION_MS
    end

    if locks.present?
      Slack::Notifier.new(
        SLACK_WEBHOOK_URL,
        channel: "pg-alerts"
      ).ping locks.to_s
    end

    blocking = RailsPgExtras.blocking(in_format: :hash).select do |block|
      (ActiveSupport::Duration.parse(block.fetch("blocking_duration")).to_f * 1000) > PG_MIN_LOCK_DURATION_MS
    end

    if blocking.present?
      Slack::Notifier.new(
        SLACK_WEBHOOK_URL,
        channel: "pg-alerts"
      ).ping blocking.to_s
    end
  ensure
    LocksMonitoringJob.perform_in(PG_MONITORING_INTERVAL_SECONDS) if ENV["PG_MONITOR_LOCKS"] == "true"
  end
end

We use an initializer file to schedule the first task and can optionally disable it by removing PG_MONITOR_LOCKS variable. The job schedules itself every configurable PG_MONITORING_INTERVAL_SECONDS and reports locks and blocked queries that cross a PG_MIN_LOCK_DURATION_MS threshold using slack-notifier gem (check out Slack docs for info on how to configure incoming webhooks). You can tweak the ENV variables to adjust monitoring sensitivity based on your app’s requirements.

If your app is running heavyweight background jobs, you’ll likely have to manually exclude some queries from being raported. And if your current database performance is far-from-perfect, you should bump up the PG_MIN_LOCK_DURATION_MS and gradually lower it when you manage fix the cause of long-lasting locks. Excluding background jobs and data migrations, a healthy database should acquire exclusive locks for a maximum of ~100-200ms.

Running a similar monitoring task can help you spot many lock-related issues early on before they start affecting end users.

Update: I’ve wrapped this implementation in a easy-to-use gem pg-locks-monitor.

So your Slack alerts channel is spammed with long-lasting locks and blocked query notifications. What now?

Overusing ActiveRecord::Base.transaction scope

I’ve seen misbehaving locks with a duration of a few seconds. Surprsingly, the underlying cause wasn’t even directly caused by the database layer. ActiveRecord makes it too easy to wrap any arbitrary chunk of code into a database transaction. Have a look at the following example:

app/models/user.rb

after_create :send_welcome_email

def send_email
  EmailSender.send_welcome_email(self)
end

ActiveRecord callbacks are a usual way to trigger side effects based on the model object’s lifecycle. For example, sending a welcome email to newly registered users is a common use case. Let’s keep discussing whether similar logic belongs in a model aside for now. Instead, let’s focus on how the database layer will react to a similar implementation.

Something to watch out for is that excluding after_commit, all the AR callbacks are implicitly wrapped in a database transaction. So, the above implementation would keep a RowExclusiveLock on the user object for the whole time needed to connect to 3rd party API and send an email. So, instead of the expected max ~200ms threshold, our lock could last up to 60 seconds in case there’s an API timeout.

This example might seem contrived. But I’ve seen multiple Rails apps suffering from long-lasting locks caused by implicit 3rd party HTTP calls executed inside database transactions.

The hidden complexity of Rails ActiveRecord makes it too easy to commit similar mistakes, even for more experienced devs. That’s why proper locks monitoring can help you spot similar issues, even if they go unnoticed during the code review.

Other ways to fix long-lasting locks

Apart from limiting the scope of ActiveRecord transactions, the “simplest” way to decrease locks duration is to optimize the performance of the database layer. Check out this blog post for an in-depth guide on analyzing and fixing PostgreSQL performance with the help of rails-pg-extras gem.

But, fine-tuning SQL queries is often a more time-involved process. So, here’s a list of “quick & easy” ad hoc solutions to try before you manage to deploy proper fixes. These are “hacks”, but they might help if your app is currently unstable because of locks-related issues.

1. Throttle Sidekiq jobs

One way to limit the occurances of locks is to reduce the concurrency of database commits. It will limit the scalability and throughput of your app. But the tradeoff might be worth it if you’re experiencing locks-related downtimes.

I usually recommend implementing the Sidekiq config file in a similar way:

config/sidekiq.yml

:concurrency: <%= ENV.fetch("SIDEKIQ_CONCURRENCY") { 5 } %>
:queues:
  - urgent
  - default
  # ...

Even if you’re currently not planning to tweak the concurrency setting, using an ENV variable will allow you to easily change this value without doing a code-change release. A panic fix could be to throttle concurrency down to 1 to minimize concurrent locks’ impact before you apply the proper solution.

Alternatively, if you know which Sidekiq job is causing the issue, you could throttle it from running concurrently with the help of the sidekiq-unique-jobs gem. This is also a good solution for more heavyweight jobs to limit the max memory usage of Sidekiq.

2. Limit the app’s concurrency

Similar throttling can be done for web app processes. Limiting your app’s concurrency could reduce performance by increasing request queue time. But, it’s possible that the throttled app will be more performant because blocking SQL queries are limited.

You can implement your Puma web server config in a similar way to easily tweak settings without a need for code release:

config/puma.rb

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
threads threads_count, threads_count
workers ENV.fetch("WEB_CONCURRENCY") { 2 }
# ...

3. Kill stuck connections

RailsPgExtras.locks and RailsPgExtras.blocking could report that a single long-running query is blocking dozens of other database commits. Depending on the scale of the issue, a similar traffic jam could cause many of your web server connections to get stuck and your app to become unresponsive. A “panic button” solution for this issue that could potentially restore your app’s responsiveness is to kill the offending connection. rails-pg-extras blocking method provides a blocking_pid value you can use to cherry-pick and terminate the stuck SQL query. Additionally, you can use RailsPgExtras.connections to verify a process name that generated the problematic query. It could be helpful for debugging.

You can terminate an SQL query/connection based on its PID value by running the following code:

RailsPgExtras.kill_pid(args: { pid: 4657 })

Optionally, if your database is a bad enough shape that killing a single connection is not enough, you can run:

RailsPgExtras.kill_all

Remember to restart all the web and background worker processes to prevent ghost connections from hanging around.

As I’ve mentioned, these are not proper fixes, but rather “band-aids” that might help in case your app is unstable.

Summary

PostgreSQL database locks usually work seamlessly behind the scenes. But, following the mentioned best practices and configuring correct monitoring can save you a lot of headaches. A proactive approach to monitoring lock-related issues can help you resolve most of the problems before they start affecting your users.

Ruby and Rust developer specializing in backend performance - Paweł Urbanek

Using LLMs and MCP to Debug PostgreSQL Performance in Rails

How to optimize PostgreSQL performance with AI?

Debugging context provided by the pg-extras gem

Automating pg-extras Performance Debugging with LLMs

Legal and security concerns of using LLMs with production data

Enabling optional EXPLAIN ANALYZE mode

How much does it cost?

Summary

My puts Debugging Workflow in Rails Apps

Why and how to puts debug Ruby code?

Introducing dbg-rb - a simple Ruby puts debugging helper

How to use dbg-rb in Rails without adding it to the Gemfile?

Summary

Lessons Learned Migrating my SAAS to Rails 8

Kamal vs Dokku

Kamal registry-based deployments

Goodbye Redis

Measuring non-memory caching performance

Using a custom compressor for Rails cache

SQLite vs PostgreSQL

Summary

How to Improve Rails Caching with Brotli Compression

Brotli vs Gzip 101

How to use Brotli for Rails cache?

Using and misusing in-memory cache store

Nested cache layers

Summary

Five Easy to Miss Performance Fixes for Rails Apps

Eliminate request queue time

Enable cache and Redis connection pool

Fine-tune database connections pool

Customize PostgreSQL config

Optimize HTTP layer config

Client-side caching

Use Cloudflare CDN

Summary

How to Freeze ETH and ERC20 Tokens using Smart Contract

Decentralized trust

Can you trust Smart Contracts?

Bugs and deliberate scams

Frontend interface

Government censorship

User error

Locker smart contracts

Locker

LockerETH

LockerPriv

LockerETHPriv

Summary

How to Find, Debug and Fix N+1 Queries in Rails

How to simulate N+1 issues in development

How to analyze and debug local N+1 issues

Use rails-pg-extras to dissect N+1 queries

Use specs to prevent N+1 queries

Summary

How to Subscribe to YouTube Channels Without an Account

How to find an RSS feed of a YouTube channel?

Summary

Easy to Overlook Way to Break Eager Loading in Rails Apps

How to use eager loading with ORDER BY in SQL?

Using custom relation to prevent N+1 queries

Summary

How to Monitor and Fix PostgreSQL Database Locks in Rails

PostgreSQL database locks 101

Monitoring PostgreSQL locks in production

How to resolve lock-related issues in Rails apps

Overusing ActiveRecord::Base.transaction scope

Other ways to fix long-lasting locks

1. Throttle Sidekiq jobs

2. Limit the app’s concurrency

3. Kill stuck connections

Summary

Introducing `dbg-rb` - a simple Ruby puts debugging helper