Fase 4: Tuning de Performance

2026-02-15

Uma rede P2P que atravessa NATs mas engasga com seu proprio I/O nao serve de -muito. A Fase 4 continua com tuning de performance: centralizacao da -configuracao do banco de dados, cache de blobs de fragmentos em memoria, -gerenciamento de ciclo de vida de conexoes QUIC e eliminacao de leituras -desnecessarias de disco no hot path de atestacao.

O principio orientador foi o mesmo do resto do Tesseras: fazer a coisa mais -simples que realmente funciona. Sem alocadores customizados, sem estruturas de -dados lock-free, sem complexidade prematura. Um StorageConfig centralizado, um -cache LRU, um reaper de conexoes e uma correcao pontual para evitar reler blobs -que ja tinham checksum calculado.

O que foi construido

Configuracao SQLite centralizada (tesseras-storage/src/database.rs) — Um -novo struct StorageConfig e funcoes open_database() / open_in_memory() que -aplicam todos os pragmas SQLite em um unico lugar: journal mode WAL, foreign -keys, modo synchronous (NORMAL por padrao, FULL para hardware instavel como -RPi + cartao SD), busy timeout, tamanho do cache de paginas e intervalo de -autocheckpoint WAL. Anteriormente, cada ponto de chamada abria uma conexao e -aplicava pragmas ad hoc. Agora o daemon, CLI e testes passam todos pelo mesmo -caminho. 7 testes cobrindo foreign keys, busy timeout, journal mode, migracoes, -modos synchronous e criacao de arquivos WAL em disco.

Cache LRU de fragmentos (tesseras-storage/src/cache.rs) — Um -CachedFragmentStore que envolve qualquer FragmentStore com um cache LRU -ciente de bytes. Blobs de fragmentos sao cacheados na leitura e invalidados na -escrita ou exclusao. Quando o cache excede seu limite de bytes configurado, as -entradas menos recentemente usadas sao removidas. O cache e transparente: ele -proprio implementa FragmentStore, entao o resto da pilha nao sabe que esta la. -Metricas Prometheus opcionais rastreiam hits, misses e uso atual de bytes. 3 -testes: hit no cache evita leitura interna, store invalida cache, remocao quando -excede bytes maximos.

Metricas Prometheus de storage (tesseras-storage/src/metrics.rs) — Um -struct StorageMetrics com tres contadores/gauges: fragment_cache_hits, -fragment_cache_misses e fragment_cache_bytes. Registrado no registry -Prometheus e conectado ao cache de fragmentos via with_metrics().

Correcao do hot path de atestacao (tesseras-replication/src/service.rs) — -O fluxo de atestacao anteriormente lia cada blob de fragmento do disco e -recalculava seu checksum BLAKE3. Como list_fragments() ja retorna FragmentId -com um checksum armazenado, a correcao e trivial: usar frag.checksum ao inves -de blake3::hash(&data). Isso elimina uma leitura de disco por fragmento -durante atestacao — para uma tessera com 100 fragmentos, sao 100 leituras a -menos. Um teste com expect_read_fragment().never() verifica que nenhuma -leitura de blob acontece durante atestacao.

Ciclo de vida do pool de conexoes QUIC -(tesseras-net/src/quinn_transport.rs) — Um struct PoolConfig controlando -maximo de conexoes, timeout de inatividade e intervalo do reaper. -PooledConnection envolve cada quinn::Connection com um timestamp -last_used. Quando o pool atinge capacidade maxima, a conexao inativa mais -antiga e removida antes de abrir uma nova. Uma tarefa reaper em background -(Tokio spawn) periodicamente fecha conexoes que ficaram inativas alem do -timeout. 4 novas metricas de pool: tesseras_conn_pool_size, pool_hits_total, -pool_misses_total, pool_evictions_total.

Integracao no daemon (tesd/src/config.rs, main.rs) — Uma nova secao -[performance] na configuracao TOML com campos para tamanho de cache SQLite, -modo synchronous, busy timeout, tamanho de cache de fragmentos, maximo de -conexoes, timeout de inatividade e intervalo do reaper. O main() do daemon -agora chama open_database() com o StorageConfig configurado, envolve -FsFragmentStore com CachedFragmentStore e vincula QUIC com o PoolConfig -configurado. A dependencia direta de rusqlite foi removida do crate do daemon.

Migracao do CLI (tesseras-cli/src/commands/init.rs, create.rs) — Ambos -os comandos init e create agora usam tesseras_storage::open_database() com -o StorageConfig padrao ao inves de abrir conexoes rusqlite diretamente. A -dependencia de rusqlite foi removida do crate do CLI.

Decisoes de arquitetura

Padrao decorator para cache: CachedFragmentStore envolve -Box<dyn FragmentStore> e implementa FragmentStore ele proprio. Isso -significa que cache e opt-in, composavel e invisivel para consumidores. O -daemon habilita; testes podem pular.
Remocao ciente de bytes: o cache LRU rastreia bytes totais, nao contagem -de entradas. Blobs de fragmentos variam muito em tamanho (um fragmento de -texto de 4KB vs um shard de foto de 2MB), entao contar entradas daria uma -visao enganosa do uso de memoria.
Sem crate de pool de conexoes: ao inves de trazer uma biblioteca generica -de pool, o pool de conexoes e um wrapper fino sobre -DashMap<SocketAddr, PooledConnection> com um reaper Tokio. Conexoes QUIC sao -multiplexadas, entao o "pool" e realmente sobre gerenciamento de ciclo de vida -(limpeza de inativos, maximo de conexoes) e nao sobre emprestar/devolver.
Checksums armazenados ao inves de releituras: a correcao de atestacao e -intencionalmente minima — uma linha alterada, uma leitura de disco removida -por fragmento. Os checksums ja estavam armazenados no SQLite por -store_fragment(), apenas nao estavam sendo usados.
Configuracao centralizada de pragmas: um unico struct StorageConfig -substitui chamadas PRAGMA espalhadas. O flag sqlite_synchronous_full -existe especificamente para implantacoes em Raspberry Pi onde o kernel pode -crashar e perder transacoes WAL nao checkpointadas.

O que vem a seguir

Fase 4 continuacao — Shamir's Secret Sharing para herdeiros, tesseras -seladas (criptografia time-lock), auditorias de seguranca, onboarding de nos -institucionais, deduplicacao de storage, empacotamento para OS
Fase 5: Exploracao e Cultura — navegador publico de tesseras por -era/localizacao/tema/idioma, curadoria institucional, integracao genealogica, -exportacao para midia fisica (M-DISC, microfilme, papel livre de acido com QR)

Com tuning de performance implementado, Tesseras lida com o caso comum de forma -eficiente: leituras de fragmentos acertam o cache LRU, atestacao pula I/O de -disco, conexoes QUIC inativas sao removidas automaticamente e o SQLite e -configurado consistentemente em toda a pilha. Os proximos passos focam em -funcionalidades criptograficas (Shamir, time-lock) e hardening para implantacao -em producao.

- -