App performance report

Snapshot read from:

Generated: 2026-05-29 10:31:46 Europe/Madrid

1. Executive summary

The app is not currently SQLite-busy. The SQLite writer looks healthy at the moment.

The main performance problem is still network/discovery latency:

connected_sync p50 = 8.67s
connected_sync p99 = 21.35s

That means user-visible document/content discovery can still take many seconds.

2. SQLite status

MetricCurrent valueWrite tx in flight0Goroutines stuck in BEGIN IMMEDIATE0Recent begin_busy events0DB size4.1 GiBWAL file size on disk41 MiBSHM file size64 KiB

SQLite page says:

No write transactions in flight right now.
Nobody is stuck in BEGIN IMMEDIATE right now.
No begin_busy events recorded yet.

So: no active SQLite lock storm right now.

SQLite write operations

CallerCountBusyp99 totalp99 holdblob.(*Index).PutMany-range1130124 ms124 mshmnet.(*Node).storeRemotePeers25047.2 ms47.0 mshmnet.(*peerWriter).flush78602.9 ms2.8 mssqlitex.WALCheckpointer266901.8 ms1.8 ms

This is good compared to the previous hmnet.(*Node).connect busy issue. In this snapshot, connect is not the SQLite write hotspot.

Slow reads

Callerp99v1alpha.(*Server).ListEntityMentions586.5 mssyncing.(*Server).loadStore173.8 msv3alpha.(*Server).ListAccounts104.7 ms

There are some moderately slow reads, but not enough to explain the 20s app delays.

3. Network status

MetricCurrent valueDaemon uptime1h28m58sPeerstore peers shown41Connected peers shown~12Protocol/hypermedia/0.9.2

Discovery latency

Phasep50p90p99Countpeer_select7 ms17 ms30 ms4177connected_sync8.67 s19.60 s21.35 s3418dht_discover500 µs900 µs991 µs2711dht_sync———0

Main bottleneck:

connected_sync

This is the phase that asks already-connected peers and waits. It dominates user-visible delay.

End-to-end discovery

Outcomep50p90p99Countconnected18.42 s20.96 s32.85 s707notfound4.94 s17.58 s21.25 s2711error8 ms24 ms93 ms753

Even successful connected discoveries are slow:

connected p50 = 18.42s
connected p99 = 32.85s

4. Peer sync health

Phasep50p90p99Countdial1 ms3.62 s18.04 s102714reconcile_rpc83 ms297 ms4.19 s21788bitswap_fetch120 ms229 ms684 ms13putmany43 ms80 ms141 ms13

Important: bitswap_fetch and putmany are not the problem. They are relatively fast and have very low counts.

The expensive path is:

dial + reconcile_rpc + waiting for connected_sync

5. Sync outcomes

OutcomeCountApprox shareok11288~11%dial_failed61590~60%preempted15848~15%rpc_error9194~9%protocol_mismatch4794~5%putmany_failed00%

This is the biggest red flag.

Most peer sync attempts do not finish successfully. The daemon is spending a lot of time attempting peers that fail, get cancelled, or error.

6. Bitswap / storage

MetricCurrentBitswap fetches13Fetch completeness1.00Idle timeouts0Context cancellations0Duplicate data6.2 KiB / 3.1%putmany_failed0

Bitswap looks healthy.

Storage persistence is also not failing:

putmany_failed = 0

7. Bandwidth

LayerTotallibp2p remote132.1 MiBHTTP server loopback165.4 MiBTotal297.4 MiB

Most traffic is split between:

local frontend/backend gRPC-Web: 155.8 MiB
remote Hypermedia protocol: 97.1 MiB combined
bitswap sent: 20.8 MiB

8. Diagnosis

Current bottleneck:

Frontend asks daemon for content
        ↓
Daemon starts discovery
        ↓
connected_sync fans out to peers
        ↓
many peer dials fail or take seconds
        ↓
many reconcile RPCs happen
        ↓
discovery waits too long
        ↓
user sees slow app

SQLite is currently not the limiting resource. The limiting resource is now mostly:

network peer sync capacity / dial success / discovery fanout

9. Recommended focus

Highest-value fixes:

Reduce discovery fanout
- do not query too many peers per document request.
Stop waiting for all connected peers
- return once enough useful peers answered.
Prioritize good peers
- avoid repeatedly dialing peers with recent failures.
Dedupe concurrent discovery
- same document/resource should share one in-flight discovery.
Cache short-term negative/positive discovery results
- avoid repeated expensive syncs for same missing content.
Keep watching SQLite
- but current snapshot says SQLite is not the active problem.

Recap

The app is currently slow because network discovery is slow, not because SQLite is locked. SQLite has 0 busy events, 0 active write transactions, and 0 goroutines stuck in BEGIN IMMEDIATE. The WAL is 41 MiB. The main issue is connected_sync: p50 8.67s, p99 21.35s, with very high dial_failed count: 61,590 out of 102,714 sync attempts.

SQLite: healthy right now; no busy storm.
Network: unhealthy; discovery and dialing dominate latency.
Bitswap/persistence: healthy; putmany_failed = 0.
Main recommendation: reduce, dedupe, and short-circuit peer discovery/sync fanout.