Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

perf(node): the Node shell runs at half the Python shell's throughput

Aperta
  • Qualcosa non va?
#962 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
nodejs, python, redis, rust
Ambito
backend, performance

Direzione di ricerca

Start by profiling one job through the Node shell in crates/flexiq-node and sdks/node, then compare its path with the Python shell for the same scenario. Check the napi boundary, codec defaults, concurrency semantics, and per-job versus per-batch work, using the benchmark comparison as the first measurement. Done means the throughput gap is explained; fix it with a regression test if it is a shell bug, or update the Node benchmark concurrency_model if the semantics differ.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement node P2 rust

Epic: #958

Why

Same core, same backend, same scenario, same machine, same run:

entrant enqueue/s completed/s p50 p99
flexiq-redis (Python) 8.1 2.1 6839 ms 8946 ms
flexiq-node-redis (Node) 7.5 1.1 9800 ms 19012 ms

Roughly half the throughput and double the tail, against the same Rust code and the same Redis.
Whatever that is, it is in the shell — crates/flexiq-node or sdks/node — not in the storage
layer both shells share, and it is therefore likely to be both cheap to find and independent of
everything else under #958.

The SQLite rows show the same sign with a much smaller magnitude, which is consistent with a
fixed per-job overhead that only becomes visible once each job is already expensive.

Shape

Profile one job end to end through the Node shell and compare the work done against the Python
shell's path for the same job. Candidates worth ruling in or out first, cheapest before
deepest:

  • an extra hop per job in the napi boundary — the Rust to JS to Rust callback is a
    ThreadsafeFunction plus Promise<Buffer> over a tokio::oneshot
  • serialization: the two shells do not default to the same codec
  • concurrency semantics — concurrency: 4 in the Node worker against workers=4 threads in
    Python is the same number and not necessarily the same amount of parallelism in flight
  • anything per job that is per batch on the Python side

Done when

  • the gap is explained, whether or not it is fixed in this issue
  • if it is a shell bug, it is fixed and a regression test covers it
  • if it is a semantic difference in what concurrency means, the benchmark's
    concurrency_model string for the Node entrant says so, because that field exists to stop
    exactly this kind of comparison being silently wrong
Lingua principale
Rust
Stelle
20
Fork
2
Merge medio
9h 49m
PR unite (30g)
72

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ByteVeda/flexiq

Tutte le issue di ByteVeda/flexiq

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.