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.