Bitcoin Forum

I’m running a Bitcoin Core full node (bitcoind) and using [romanz/electrs (via Docker)][1] 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][2] 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

  explorer:
    container_name: btc-rpc-explorer
    environment:
      BTCEXP_HOST: $BTCEXP_HOST
      BTCEXP_PORT: $BTCEXP_PORT
      BTCEXP_ADDRESS_API: $BTCEXP_ADDRESS_API
      BTCEXP_ELECTRUM_SERVERS: $BTCEXP_ELECTRUM_SERVERS
      BTCEXP_ELECTRUM_TXINDEX: $BTCEXP_ELECTRUM_TXINDEX
      BTCEXP_BITCOIND_URI: $BTCEXP_BITCOIND_URI
      BTCEXP_BITCOIND_USER: $BTCEXP_BITCOIND_USER
      BTCEXP_BITCOIND_PASS: $BTCEXP_BITCOIND_PASS
      BTCEXP_BITCOIND_RPC_TIMEOUT: $BTCEXP_BITCOIND_RPC_TIMEOUT
      BTCEXP_SECURE_SITE: $BTCEXP_SECURE_SITE
      BTCEXP_COIN: $BTCEXP_COIN
      BTCEXP_RPC_CONCURRENCY: $BTCEXP_RPC_CONCURRENCY
      BTCEXP_SLOW_DEVICE_MODE: $BTCEXP_SLOW_DEVICE_MODE
      BTCEXP_NO_RATES: $BTCEXP_NO_RATES
      BTCEXP_RPC_ALLOWALL: $BTCEXP_RPC_ALLOWALL
      BTCEXP_UI_TIMEZONE: $BTCEXP_UI_TIMEZONE
      BTCEXP_UI_THEME: $BTCEXP_UI_THEME
    build:
      context: ./btc-rpc-explorer/.
    image: btc-rpc-explorer:latest
    volumes:
      - bitcoin_volume:/home/btc-user/.bitcoin:ro    # Mount same bitcoin data volume (read-only)
    networks:
      network:
        ipv4_address: 192.168.1.222
    ports:
      - "3002:3002"
    depends_on:
      electrs:
        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!


  [1]: https://github.com/romanz/electrs
  [2]: https://github.com/janoside/btc-rpc-explorer

The only detailed benchmark/measure about Electrum server (that i remember) is https://www.sparrowwallet.com/docs/server-performance.html (https://www.sparrowwallet.com/docs/server-performance.html). That benchmark also state Fulcrum have best performance (comapred with electrs and ElectrumX), so you may want to consider switch to Fulcrum.

thanks bro fulcrum seems pretty decent i will try it :)

For uncached queries or cold queries, this latency is within the normal range. But for hot queries with your SSD + 4 threads + 4GB DB cache, you could have achieved 60-150 ms. For your case, it could be RocksDB scans (especially with large address histories).
You could add this on your env for reducing RocksDB scan depth when querying addresses with long histories, it can speedup your queries.

Can you tell us which version of romanz/electrs you use for that environment variable? I just searched it on google, but there's no search result. Although searching other electrs env on google shows shows some result.

https://i.ibb.co/k6vHxgkf/e.png (https://ibb.co/0VvDcj8S)

I appreciate you double checked that. My apologies for making the assumption that custom Electrs forks or internal builds might implement history truncation for performance, especially in Lightning-related setups.Where pruning long address history for faster queries.

I didn’t actually use any specific version of romanz/electrs that supports ELECTRS_TRUNCATE_HISTORY. It was my misunderstanding ,  I’ve corrected my understanding and won’t pass that along without verifying in the future.

i got this on electrs logs Any clue how to get rid of it
"electrs             [2025-05-28T21:16:53.327Z INFO  electrs::electrum] your wallet uses less efficient method of querying electrs, consider contacting the developer of your wallet. Reason: blockchain.scripthash.get_balance called for unsubscribed scripthash"

It's pertaining to that electrum protocol used by btc-rpc-explorer to query an address' balance, "blockchain.scripthash.get_balance",
As the warning shows; your btc-rpc-explorer is not set or can't be set to call "blockchain.scripthash.subscribe" for it to be efficient.
Unfortunately, I can't find any reference of that electrum protocol method in their code or specifically in .../electrumAddressApi.js (https://github.com/janoside/btc-rpc-explorer/blob/master/app/api/electrumAddressApi.js) (I may have missed it though)

Since you already re-posted this to their GitHub repo as a new issue, you may as well mention this error there since it's better to ask the main developers themselves.