dd-trace-js

This benchmark suite measures the performance overhead of Datadog's Interactive Application Security Testing (IAST) feature. It drives real Express.js request handling with the tracer loaded to compare the per-request taint-tracking overhead across different configurations:

• IAST Off vs. On: Comparing baseline performance against IAST-enabled performance.
• Sampling Modes: Evaluating performance with default sampling versus always-active IAST.
• Endpoint Types: Measuring overhead on both a non-vulnerable endpoint and an endpoint containing a command-injection sink that triggers vulnerability reporting.

The plugin-grpc benchmark measures the performance of the gRPC client plugin's bindStart operation. This operation involves resolving method metadata from a specific path (formatted as /pkg.Service/Method) and assembling the method metadata bag. The metadata for a path is parsed once and then cached for subsequent uses.

Benchmark variants include:

• A single unary method.
• A mix of methods representing a typical service definition.

The llmobs-evaluations benchmark suite measures the egress performance of the LLMObs evaluation-metrics writer. It specifically evaluates the efficiency of the append operation (including buffer management and byte sizing) and the flush operation (which involves makePayload, _encode, and JSON.stringify using the encodeUnicode replacer).

This benchmark is distinct from the llmobs (span writer) benchmark because it focuses on the specific payload shapes used by the evaluations writer. The suite includes several variants to test different data types and encoding paths:

• Categorical metrics: Tests standard categorical data.
• Score metrics: Tests numerical score-based metrics.
• Reasoned metrics: Tests metrics containing non-ASCII text to exercise the encodeUnicode logic path.

The cassandra-driver plugin for dd-trace measures the bindStart operation. It is designed to capture and process Cassandra queries by:

• Combining a batch of statements into a single resource string.
• Trimming single long statements that exceed 5000 characters.
• Assembling the metadata bag for the trace.

Benchmarks for this plugin cover three specific scenarios:

1. A single query.
2. A batch of statements.
3. An over-long query that triggers the statement trimming logic.

The llmobs-span-processor benchmark is designed to measure the performance of LLMObsSpanProcessor.format(). This method is executed once per finished LLMObs span.

Its primary function is to transform data from two sources:

1. The tagger's per-span tag map.
2. The APM span tags.

From these sources, it constructs an LLMObs event containing kind-specific input/output, metadata, metrics, tags, and error information. This benchmark specifically targets the per-span formatting logic that feeds into the writer encode process.

Note: Because this process allocates memory per call, it is expected to be GC-noisy in local environments. In CI environments, performance is gated by the pinned core.

This benchmark measures the performance impact of the per-message Data Streams Monitoring (DSM) hot path when using kafkajs.

Specifically, it evaluates the overhead of the producer's logic, which includes:

1. Calculating message size via getMessageSize.
2. Encoding the pathway context using DsmPathwayCodec.encode (which uses varint-encoding into a reused scratch buffer).
3. Base64-encoding the resulting context into the message headers.

The benchmark covers three distinct scenarios:

• A small keyed message.
• A larger message containing user headers.
• A mixed batch of messages.

This benchmark measures the performance overhead of injecting Datadog trace context into pino JSON logs. Specifically, it evaluates the combined cost of:

1. LogPropagator.inject: The process of building the dd field, which includes 128-bit trace/span IDs and metadata like service, version, and env.
2. handleJsonLine splice: The operation that inserts the ,"dd":{...} string into the JSON line already produced by pino.

Both operations occur once per log record on the logging hot path, making this benchmark relevant for high-volume structured logging environments.

This benchmark measures the specific performance overhead added by dd-trace when instrumenting fs (filesystem) calls.

To isolate the tracer's cost from actual filesystem syscall noise, the benchmark uses a 'no-op' underlying operation. This ensures the measured latency is strictly the cost of the tracer's internal logic, including:

• The orphan guard
• The getMessage-shape context (ctx) building
• AbortController allocation
• The execution of the two startChannel/finishChannel runStores around the operation.