Backend performance, deployment and limits

This chapter is for deciding whether the backend fits a service, and for putting it into production once it does: what it costs in time and memory compared with the alternatives, how the binary ships, and the limits worth knowing first.

Same handler, three ways, plus Go for an outside reference. Two pinned cores, 64 connections, medians of three interleaved runs on the plaintext route:

Cold start is the interesting column. It’s measured from process spawn to the first accepted connection, and the static binary reaches it in under a millisecond — about a hundred times faster than the same code on a JVM, and three times faster than Go. That number is the whole serverless argument.

Throughput is the least interesting one. Beating a tuned Go server by a fifth on a microbenchmark isn’t a reason to move a service; it’s only evidence that the translation doesn’t cost you anything.

The slope chart is the one that matters. Every runtime here has a similar median. What differs is the distance to the 99th percentile, and that distance is garbage collection. With the response pooled the plaintext route allocates about 0.1 bytes per request, the collector never runs, and the tail stays at 2.8 times the median. Give the same server a handler that allocates a map per request and its tail goes to 80 ms, because the collector shares the cores with the server.

The honest rule is that the tail follows your allocation rate, not the runtime badge. The runtime gives you the tools to allocate nothing on the hot path; it doesn’t do it for you.

The JVM row is the same handler and the same protocol code. Everything it costs above the native rows is the runtime underneath it.

The resident figures move around more than the latency ones, because the collector keeps a pool of pages sized to the busiest moment the process has seen and gives them back gradually. At rest the native builds sit near 3 MB.

Both are supported, and they aren’t equivalent. The static musl build starts faster and has a far shorter tail. The glibc build has a better median, because its allocator is better under contention, and a smaller binary, because it links the system libraries instead of carrying them.

The reason to pick musl isn’t the median. It’s that the artifact is one file with nothing underneath it, which is what makes the container the binary and the cold start a process exec.

GraalVM is missing from these tables on purpose. A fair comparison would have to run the same handler, and this handler can’t run on GraalVM: the runtime’s native methods are ParparVM’s, so comparing would mean benchmarking a different server written against a different framework and reporting it as though the toolchains had been compared. That’s a benchmark worth building, and it isn’t this one.

The musl build is a single static file, so the container that carries it can be empty:

There is no base image to patch, because there is no base image. cn1:backend-package builds for the machine it runs on; the cross-compiled targets (musl-x86_64, musl-arm64, glibc-x86_64, glibc-arm64) are produced by vm/backend/package.sh in the Codename One repository, which drives one builder image per target.

For AWS Lambda, LambdaRuntime implements the custom runtime loop. The Lambda Runtime API is a plaintext poll over loopback, so it needs no listening socket and no TLS, and what it does need is exactly what a translated binary is good at.

The reasons to choose this are cold start, footprint, deployment shape, and one language across the app and its server. If none of those matter for the service in front of you, use a JVM framework.

Backend applications use the shared com.codename1.io.ProcessBuilder and com.codename1.io.Process API described in Desktop and Backend Processes. The same API serves JavaSE and native desktop applications. Request-scoped children must be closed on completion or cancellation; long-lived children belong to a managed bean with a @PreDestroy cleanup method. A timed wait doesn’t itself terminate a child. See that chapter for pipe draining, virtual-thread behavior, platform restrictions, and the differences from JavaSE.

ParparVM provides the streaming subset of java.util.zip in its Java runtime. The same API is declared in the mobile compile-time library. It includes ZipEntry, ZipInputStream, ZipOutputStream, Deflater, Inflater, DeflaterOutputStream, InflaterInputStream, GZIPInputStream, GZIPOutputStream, Checksum, CRC32, Adler32, CheckedInputStream, CheckedOutputStream, ZipException, and DataFormatException. Compression uses the existing pure-Java JZlib engine. JVM and Android targets use their platform implementation of the standard classes.

This is a streaming API, not the entire Java SE ZIP package. Random-access ZipFile, reverse compression filters, and the FileTime methods on ZipEntry aren’t provided. Reading a ZIP entry verifies its CRC and sizes when its end is reached; call closeEntry() to consume and verify an entry you have only partly read. Closing the input stream doesn’t drain or verify unread entries. ZIP input doesn’t extract files or interpret Unix permissions.

Java SE’s ZipEntry has no setter for Unix external attributes. Use com.codename1.io.zip.ZipArchiveOutputStream when an extracted launcher must remain executable. It accepts standard ZipEntry objects and adds putNextEntry(entry, permissions). This helper runs with both JVM and ParparVM compression and writes the Unix creator platform and external attributes in the central directory.

The permission argument accepts 0000 through 0777. The writer infers a regular file or directory from the trailing slash; it doesn’t create symlinks or special files. Use 0644 for ordinary files. Names are archive paths with / separators. The writer doesn’t sanitize names for extraction, so choose relative names without .. components.

The runnable example is vm/backend/demo/zipdownload/com/demo/ZipDownload.java. It serves a small, fixed project at http://127.0.0.1:8099/project.zip:

The same binary can generate a file without starting HTTP: /tmp/zipdownload --write /tmp/project.zip. Extract it with unzip, then run project/run.sh. The JVM version can be run with CN1_BACKEND_DEMO=demo/zipdownload ./run-javase.sh com.demo.ZipDownload.

HttpServer.Response.stream invokes the writer when it sends the response. Open sources inside this callback and close them with try-with-resources. HEAD and statuses without a body don’t invoke it, so they don’t open sources. Closing the supplied output flushes it without closing the connection. The server ends the response only after the callback returns successfully.

Generation uses the serving worker and fixed transport buffers: 16 KiB for HTTP/1, plus a 16 KiB receive buffer and a 16 KiB native chunk for HTTP/2. It creates no archive-sized byte array, temporary file, or producer thread. HTTP/1.1 uses chunked framing, HTTP/1.0 closes the connection after the body, and native HTTP/2 respects the client’s flow-control window. A slow client holds the serving worker until it grants credit or the socket deadline expires; other streams on that HTTP/2 connection wait while the callback runs.

A disconnected client, HTTP/2 reset, or socket timeout makes output writes throw IOException. Let that exception propagate so source cleanup runs and archive generation stops. Cancellation is detected on output I/O; a callback doing lengthy computation or waiting on its own source must bound that work itself. A callback failure aborts the response rather than emitting a success terminator. The local JVM transport supports HTTP/1; test HTTP/2 with the packaged backend.

These explicit ZIP limits belong to the ParparVM implementation and the CN1 helper. The platform’s own java.util.zip.ZipOutputStream may have broader limits, including ZIP64 support.