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.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime