Limits, bottlenecks and next steps

HarvTTP works as a CPU-real boot-ROM, ELF and HNET demonstrator. PHP, SQL and WordPress experiments now stress parts of the system that a production OS would normally delegate to a supervisor, a mature network stack and a larger runtime.

Current bottlenecks

Area	Why it matters	Current mitigation
Cooperative scheduler	A long Zend or OPcache phase can delay RX/TX work if it does not pump often enough.	Four HTTP workers, heartbeat streaming and explicit host/network pumps during heavy PHP work.
PHP request queue	Only eight PHP jobs are queued; overloaded WordPress paths can produce `HarvTTP PHP worker queue full`.	Bounded queue, worker restarts and diagnostics instead of unbounded memory growth.
TCP stack	The minimal in-order TCP path lacks full retransmission, congestion control and window scaling.	Short HTTP/1.0 responses, peer aging, TX queue and batch flushing.
HNET ownership	The NIC MMIO path is currently single-owner, which complicates independent HarvTTP and HarvSQL ELFs.	HarvTTP SQL loopback until a supervisor or network daemon owns the device.
PHP memory	Zend, WordPress and OPcache need far more heap, stack and mmap-style memory than the original static server.	Reduced OPcache defaults, fixed mmap arena and strict per-request buffers.
HarvSQL	The SQL service is intentionally small and only implements the subset required for current experiments.	Deterministic fixed limits, seed scripts and MySQL protocol compatibility for simple clients.

Stress-test tendency

Low concurrency is stable enough for smoke tests and demos. Higher concurrency exposes the cost of HTTP/1.0 close-per-request behavior, the small DMA window, minimal TCP and cooperative PHP scheduling. Full WordPress bootstrap is currently a worst-case test because it combines filesystem traversal, PHP module startup, OPcache metadata and SQL access.

Why this is not production HTTP yet

The TCP implementation is intentionally minimal.
There is no TLS, certificate handling, HTTP/2 or persistent connection pool.
There is no complete process isolation for multiple long-running service ELFs.
Filesystem access is still split between preloaded bundles, data-image paths and compatibility glue.
PHP/Zend works through a bounded embedded SAPI path, not a full Unix-like process model.
Request limits, upload limits, DoS protection and privilege separation need supervisor enforcement.

Recommended expansion

Load a supervisor or microkernel as the first long-running ELF.
Move task creation, scheduling, MMU policy, VFS and device access into that supervisor.
Let a single network service own HNET and multiplex HarvTTP, HarvSQL and future services.
Replace single-frame DMA transfers with descriptor rings and stronger backpressure.
Port or adapt a fuller TCP/IP stack to HarvOS instead of extending the demo TCP code indefinitely.
Give PHP a larger per-task heap/stack model and a real VFS bridge for WordPress files.
Grow HarvSQL toward the SQL features WordPress actually depends on during install, login and admin flows.
Add signed webroot manifests, MIME allowlists, upload limits and crash recovery.

Target architecture

Boot ROM
  initializes minimal hardware
  validates bootloader or supervisor
  loads the supervisor into IMEM/DMEM
  locks immutable code regions

Supervisor / microkernel
  owns MMU, tasks, IRQs, HNET, USB and block images
  loads service ELFs from the program USB
  maps YAML configuration and data directories
  exposes VFS, netd, timers and crash recovery

HarvTTP
  runs as an isolated task
  uses supervisor network and filesystem services
  executes static files, PHP/Zend requests and WordPress routes

HarvSQL
  runs as an isolated task
  exposes a MySQL-compatible endpoint through netd
  persists catalog data through the supervisor VFS