Why Are Electrs Address Balance Queries Slow (~900ms) on My Dockerized Bitcoin Full Node?

I’m running a Bitcoin Core full node (bitcoind) and using romanz/electrs (via Docker) to provide Electrum server functionality for querying address balances and related wallet info. However, I’m experiencing unexpectedly high latency: querying the balance for a random address consistently takes around 600-900 ms via btc-rpc-explorer RPC interface. For addresses with an enormous number of transactions, the query can take some seconds instead of ms

This is the docker compose yml file:

services:
  bitcoin_service:
    build:
      context: .
      dockerfile: Bitcoin.Dockerfile
      args:
        BITCOIN_VERSION: ${BTC_VERSION}
    image: bitcoin_full_node
    ports:
      - 8333:8333
      - 8332:8332
    volumes:
      - bitcoin_volume:/home/btc-user/.bitcoin
    networks:
      network:
        ipv4_address: 192.168.1.219
    healthcheck:
      test: [
        "CMD",
        "bitcoin-cli",
        "-rpccookiefile=/home/btc-user/.bitcoin/btc.cookie",
        "-rpcport=8332",
        "-rpcconnect=192.168.1.219",
        "getblockchaininfo"
      ]
      interval: 40s
      timeout: 60s
      retries: 45

  electrs:
    image: electrs:latest
    build:
      context: ./electrs/.
    container_name: electrs
    restart: always
    ports:
      - "50001:50001"    # Electrum TCP port exposed on host and container
    environment:
      - ELECTRS_NETWORK=bitcoin
      - ELECTRS_DAEMON_RPC_ADDR=192.168.1.219:8332
      - ELECTRS_DAEMON_P2P_ADDR=192.168.1.219:8333
      - ELECTRS_ELECTRUM_RPC_ADDR=192.168.1.223:50001
      - ELECTRS_LOG_FILTERS=INFO
      - ELECTRS_DB_DIR=/home/electrs/db
      - ELECTRS_VERBOSE_RPC_LOGS=true
      - ELECTRS_IGNORE_MEMPOOL=true
      - ELECTRS_TIMESTAMP_CACHE_CAPACITY=1000000  # Higher cache for faster lookups
      - ELECTRS_INDEX_LOOKUP_LIMIT=10000
      - ELECTRS_COOKIE_FILE=/home/btc-user/.bitcoin/btc.cookie
      - ELECTRS_THREADS=4
      - ELECTRS_DB_CACHE_SIZE=4096
    volumes:
      - electrs_db:/home/electrs/db
      - bitcoin_volume:/home/btc-user/.bitcoin:ro    # Mount same bitcoin data volume (read-only)
    networks:
      network:
        ipv4_address: 192.168.1.223 # new IP in the same subnet
    healthcheck:
      test: ["CMD-SHELL", "timeout 5 bash -c 'echo > /dev/tcp/192.168.1.223/50001'"]
      interval: 40s
      timeout: 60s
      retries: 45
    depends_on:
      bitcoin_service:
        condition: service_healthy

My Setup:

Bitcoin Core runs as a full node with default (non-pruned) settings.
Electrs runs in Docker with the following environment:
ELECTRS_NETWORK=bitcoin
ELECTRS_DAEMON_RPC_ADDR=192.168.1.219:8332
ELECTRS_DAEMON_P2P_ADDR=192.168.1.219:8333
ELECTRS_ELECTRUM_RPC_ADDR=192.168.1.223:50001
ELECTRS_DB_DIR=/home/electrs/db
ELECTRS_TIMESTAMP_CACHE_CAPACITY=1000000
ELECTRS_INDEX_LOOKUP_LIMIT=10000
ELECTRS_THREADS=4
ELECTRS_DB_CACHE_SIZE=4096
Volumes: bitcoin data (read-only) and electrs DB (persistent)
Docker container has 4 threads and 4GB cache configured

Electrs and bitcoind are on the same local network. Problem: Despite this setup, querying a single, random address balance via Electrs takes about 900ms. This seems slow compared to other Electrum servers and my expectations for local, SSD-backed infrastructure.

Hardware Specs:

  • CPU: AMD Ryzen 5 5600 3.5 GHz 6-Core Processor
  • RAM: 16 GB (2 x 8GB) DDR4-3200
  • Storage: Western Digital Blue SN580 2TB NVMe M.2 SSD (PCIe 4.0 x4)
  • Motherboard: Gigabyte A520M K V2 Micro ATX AM4
  • Network: 1GPS Download speed

Questions:

  • Is this latency typical for Electrs on a Dockerized full node?
  • Are there further optimizations I can make in my Docker or Electrs configuration to reduce balance query times?
  • Is there any known bottleneck, either in RocksDB, disk I/O, or Docker networking, that might cause this?
  • What are the typical response times others see for similar setups?

Any insights or tuning suggestions from the community would be greatly appreciated!

Thank you!



from Recent Questions - Bitcoin Stack Exchange https://ift.tt/mJ6t5IV
via IFTTT

Popular posts from this blog

Future of Bitcoin encryption and security in a QC era

How will the advancement of quantum computing impact the security of Bitcoin, and what steps are necessary to protect the network from this emerging threat? What role could lattice-based encryption play in safeguarding Bitcoin, and which of the current algorithms are best suited for this purpose? How would the implementation of such encryption technology be integrated into the existing Bitcoin infrastructure, and what challenges might arise during this process? What happens to existing addresses that rely on elliptic curve cryptography? Is there a way to seamlessly transition old addresses to the new system, or would users need to actively transfer their funds to new, more secure addresses? How could such a transition be designed to ensure user security while maintaining trust in the network? from Recent Questions - Bitcoin Stack Exchange https://ift.tt/aZeY2fo via IFTTT
Read more

Possible rollback due to lazy reveal in BRC20?

Let's assume user A committed an inscription with {"op":"deploy", "tick": "test"} at block 100 (without revealing it yet). Then user B commits and reveals the exact same inscription at block 101. Because the indexer isn't aware that A's earlier commit was actually for "test," it recognizes B's "test" token as the official one. From blocks 101 to 199, users freely perform various "test" token transactions (e.g., "mint" , "transfer" ). However, at block 200, user A finally reveals their earlier commit. In that case, will the indexer roll back all "test"-related histories that happened between blocks 101 and 199? If so, can we really trust that all BRC20 tokens recognized by the indexer are "safely" the official ones? from Recent Questions - Bitcoin Stack Exchange https://ift.tt/CsYKVTa via IFTTT
Read more

A way to recover scammed Bitcoin investment

I have learned the hard way that even the most seasoned investors can fall prey to malicious actors. When my Investment was stolen, I felt a sense of betrayal and anger. But then, I discovered this FINANCE TEAM, and their professionalism and unwavering commitment gave me a renewed sense of confidence. From the moment I reached out to this Finance Team, I was impressed by their attention to detail and their deep understanding of the Stock and real estate ecosystem. They listened patiently to my story and carefully analyzed the transaction history, leaving no stone unturned in their investigation. Throughout the recovery process, This Finance Teamkept me informed of their progress, providing me with regular updates and answering my countless questions with patience and understanding. Their unwavering dedication and determination gave me a sense of hope during a time of great uncertainty. To my astonishment, This Finance Team was able to recover a significant portion of my stolen Investme...
Read more