<a id="performance_configuration" class="anchor" href="#performance_configuration">&nbsp;</a>

<a id="memory_tuning" class="anchor" href="#memory_tuning">&nbsp;</a>

<h2>Memory Tuning Guide</h2>

<p>MockServer stores expectations and log entries in memory using ring buffers. The two most important settings that affect memory usage are <a href="#button_configuration_max_expectations">maxExpectations</a> and <a href="#button_configuration_request_log_size">maxLogEntries</a>. Each HTTP request processed by MockServer generates 2-3 log entries (the request itself, the expectation match result, and the response).</p>

<p>Both settings have automatic defaults based on available JVM heap space. The table below provides recommended values if you want to override the defaults for different heap sizes:</p>

<table>
    <tr>
        <th>JVM Heap Size</th>
        <th>maxExpectations</th>
        <th>maxLogEntries</th>
        <th>Approx HTTP Requests Retained</th>
    </tr>
    <tr>
        <td>256 MB</td>
        <td>1,000</td>
        <td>5,000</td>
        <td>~1,500 - 2,500</td>
    </tr>
    <tr>
        <td>512 MB</td>
        <td>2,000</td>
        <td>15,000</td>
        <td>~5,000 - 7,500</td>
    </tr>
    <tr>
        <td>1 GB</td>
        <td>5,000</td>
        <td>40,000</td>
        <td>~13,000 - 20,000</td>
    </tr>
</table>

<p>These are conservative estimates assuming typical request/response sizes of 1-5 KB. Large request or response bodies will consume more memory per entry.</p>

<p><strong>Tips for reducing memory usage:</strong></p>
<ul>
    <li>Reduce <a href="#button_configuration_request_log_size">maxLogEntries</a> to limit the number of stored request/response log entries</li>
    <li>Reduce <a href="#button_configuration_max_expectations">maxExpectations</a> if expectations contain large response bodies</li>
    <li>Increase JVM heap size (<span class="inline_code">-Xmx</span>) to give the garbage collector more headroom</li>
    <li>Use <a href="#button_configuration_log_memory_statistics">outputMemoryUsageCsv</a> to monitor actual heap usage and tune values accordingly</li>
</ul>

<p>Docker example with memory-constrained settings:</p>
<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  --env MOCKSERVER_MAX_EXPECTATIONS=1000 \
  --env MOCKSERVER_MAX_LOG_ENTRIES=5000 \
  mockserver/mockserver</code></pre>

<button id="button_configuration_connection_delay_millis" class="accordion title"><strong>Connection Delay</strong></button>
<div class="panel title">
    <p>Introduces a delay (in milliseconds) before protocol detection on new TCP connections. This can be used to simulate slow connection establishment, such as when testing client timeout handling or connection pooling behaviour under latency.</p>
    <p>Type: <span class="keyword">long</span> Default: <span class="this_value">0</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.connectionDelayMillis(long millis)</code></pre>
    <pre class="prettyprint lang-java code"><code class="code">Configuration.connectionDelay(Delay delay)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.connectionDelayMillis=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_CONNECTION_DELAY_MILLIS=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.connectionDelayMillis=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.connectionDelayMillis="500"</code></pre>
</div>

<a id="troubleshooting_performance" class="anchor" href="#troubleshooting_performance">&nbsp;</a>

<h2>Troubleshooting: MockServer Becomes Slow or Unresponsive</h2>

<p>If MockServer appears to freeze, hang, or become progressively slower under sustained load, the most likely cause is <strong>memory pressure</strong> from log entry accumulation. This section explains why it happens and how to fix it.</p>

<h3>Why Does MockServer Slow Down?</h3>

<p>Every HTTP request that MockServer processes generates 2-3 log entries that are stored in memory regardless of the configured log level. These entries record the received request, expectation match result, and response &mdash; they are always stored to support request verification. Each log entry consumes approximately 4-10 KB of heap for small request/response bodies, scaling proportionally for larger bodies. Under sustained high-throughput load, log entry allocation drives significant GC pressure:</p>

<table>
    <tr>
        <th>Request Rate</th>
        <th>Response Body Size</th>
        <th>Log Data Generated Per Minute</th>
    </tr>
    <tr>
        <td>1 req/s</td>
        <td>1 KB</td>
        <td>~1 MB</td>
    </tr>
    <tr>
        <td>10 req/s</td>
        <td>1 KB</td>
        <td>~12 MB</td>
    </tr>
    <tr>
        <td>10 req/s</td>
        <td>100 KB</td>
        <td>~120 MB</td>
    </tr>
    <tr>
        <td>1 req/s</td>
        <td>1 MB+</td>
        <td>~120 MB</td>
    </tr>
</table>

<p>Log entries are stored in a bounded circular queue (<span class="inline_code">maxLogEntries</span>), so total memory usage does not grow indefinitely. However, the constant allocation and eviction of log entries creates GC pressure. When the JVM heap fills up, the garbage collector runs more frequently and for longer, causing pauses that make MockServer appear to freeze. In extreme cases, the JVM may spend almost all of its time in garbage collection, effectively halting request processing.</p>

<p><strong>Large response bodies amplify this problem significantly.</strong> A single expectation returning a 10 MB response at 1 request per second generates over 600 MB of log data per minute &mdash; far more than a default heap can handle. Even with ring buffer eviction, the JVM must allocate and then garbage-collect these large objects continuously.</p>

<p><strong>Note:</strong> Expectations with large response bodies also consume heap proportionally (e.g., a 50 KB response body results in ~55-75 KB per stored expectation). If you have many expectations with large bodies, reduce <span class="inline_code">maxExpectations</span> as well.</p>

<h3>How To Fix It</h3>

<p>Apply one or more of the following, depending on your use case:</p>

<table>
    <tr>
        <th>Fix</th>
        <th>When To Use</th>
        <th>Trade-off</th>
    </tr>
    <tr>
        <td>Increase JVM heap size</td>
        <td>Always recommended for large responses or high request rates</td>
        <td>Uses more container/host memory</td>
    </tr>
    <tr>
        <td>Reduce <span class="inline_code">maxLogEntries</span></td>
        <td>The single most effective fix &mdash; fewer entries means less memory and less GC pressure</td>
        <td>Fewer requests available for verification</td>
    </tr>
    <tr>
        <td>Reduce <span class="inline_code">maxExpectations</span></td>
        <td>When expectations contain large response bodies</td>
        <td>Fewer expectations can be stored simultaneously</td>
    </tr>
    <tr>
        <td>Switch to ZGC (<span class="inline_code">-XX:+UseZGC</span>)</td>
        <td>Heap &ge; 4 GB and matcher latency matters &mdash; typically gives single-digit-millisecond GC pauses where G1 commonly sits in the 50&ndash;200 ms range under sustained allocation</td>
        <td>Fixed memory overhead (less attractive below ~4 GB); set <span class="inline_code">-Xms</span> and <span class="inline_code">-Xmx</span> to the same value (e.g. <span class="inline_code">-Xms4g -Xmx4g</span>) so the heap is pre-committed</td>
    </tr>
</table>

<p><strong>Note on GC selection:</strong> Java 17 makes ZGC production-ready in every JDK distribution MockServer supports. For deployments with deep ring buffers (high <span class="inline_code">maxLogEntries</span>) or large heaps, <span class="inline_code">-XX:+UseZGC</span> can reduce p99 matcher latency by holding stop-the-world pauses to the single-digit-millisecond range (typically 1&ndash;5 ms in Java 17's non-generational ZGC). For small-fixture deployments (a sidecar in a test pipeline), the default GC is fine &mdash; ZGC's fixed overhead isn't worth it below ~4 GB heap. In containerised deployments using ZGC, size the container memory limit at ~1.5&times; your <span class="inline_code">-Xmx</span> value to leave headroom for JVM overhead (code cache, metaspace, thread stacks) and Netty's direct buffer pool. Note that ZGC multi-maps the same physical pages for its coloured-pointer scheme; under some cgroup RSS-accounting modes those pages are counted multiple times against the container limit, so the process can be OOM-killed even though the actual physical footprint fits (e.g. <span class="inline_code">-Xmx4g</span> &rarr; <span class="inline_code">--memory=6g</span>). Shenandoah is not recommended &mdash; it is not available in Oracle JDK 17 and not universally available across all JDK distributions, so ZGC is the simpler choice.</p>

<p><strong>Note on <span class="inline_code">logLevel</span> and <span class="inline_code">disableLogging</span>:</strong> Setting <span class="inline_code">logLevel</span> to <span class="inline_code">WARN</span> reduces diagnostic TRACE/DEBUG log entries but does <strong>not</strong> prevent request/response recording &mdash; the memory-intensive log entries (received requests, matched expectations, and responses) are always stored regardless of log level, as they are required for verification. Similarly, <span class="inline_code">disableLogging</span> only suppresses system-out output and does not reduce memory usage. To reduce memory, lower <span class="inline_code">maxLogEntries</span> or increase heap size.</p>

<p><strong>Note on <span class="inline_code">logLevel</span> and matching throughput:</strong> while <em>stored</em> log entries are independent of log level (above), the <em>transient</em> per-request allocation on the matching hot path is not. At <span class="inline_code">INFO</span>, every request that scans expectations builds and logs a diagnostic &ldquo;matched&rdquo;/&ldquo;did not match because&hellip;&rdquo; message per matcher; below <span class="inline_code">INFO</span> that work &mdash; the per-matcher log entry and the human-readable &ldquo;because&rdquo; string assembly &mdash; is skipped entirely. For a deployment with many expectations under sustained load this is the single largest matching-path allocation, so running at <span class="inline_code">WARN</span> noticeably cuts allocation churn and GC pressure (it does not change which requests match, only whether the diagnostic narrative is produced). This is purely a throughput/GC lever; it is independent of the steady-state memory footprint controlled by <span class="inline_code">maxLogEntries</span>.</p>

<h3>Recommended Configurations</h3>

<p><strong>High-throughput with small responses</strong> (e.g., API mocking at &gt;10 req/s with &lt;10 KB bodies):</p>
<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  -e MOCKSERVER_MAX_LOG_ENTRIES=5000 \
  mockserver/mockserver</code></pre>

<p><strong>Large response bodies</strong> (e.g., responses &gt;100 KB):</p>
<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  -e JAVA_TOOL_OPTIONS="-Xmx1g" \
  -e MOCKSERVER_MAX_LOG_ENTRIES=1000 \
  -e MOCKSERVER_MAX_EXPECTATIONS=100 \
  mockserver/mockserver</code></pre>

<p><strong>Maximum throughput, minimal memory</strong> (verification limited to most recent requests):</p>
<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  -e JAVA_TOOL_OPTIONS="-Xmx512m" \
  -e MOCKSERVER_MAX_LOG_ENTRIES=100 \
  -e MOCKSERVER_LOG_LEVEL=WARN \
  mockserver/mockserver</code></pre>
<p><span class="inline_code">MOCKSERVER_LOG_LEVEL=WARN</span> drops the per-matcher diagnostic logging on the matching hot path (see the note above), which is the largest matching-path allocation when many expectations are registered. If your matchers rely heavily on regular expressions <em>and</em> your patterns and inputs are trusted, also add <span class="inline_code">-e MOCKSERVER_REGEX_MATCHING_TIMEOUT_MILLIS=0</span> to evaluate regexes inline and skip the per-regex thread hand-off (this removes the catastrophic-backtracking guard &mdash; see <a href="#button_configuration_regex_matching_timeout_millis">Regex Matching Timeout</a>).</p>

<h3>Configuring JVM Heap Size</h3>

<p>The default JVM heap in the MockServer Docker image is determined by the JVM's container-aware defaults (typically 25% of the container's memory limit). To set an explicit heap size, use the <span class="inline_code">JAVA_TOOL_OPTIONS</span> environment variable:</p>

<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  -e JAVA_TOOL_OPTIONS="-Xmx512m" \
  mockserver/mockserver</code></pre>

<p>When running with docker compose:</p>
<pre class="prettyprint lang-yaml code"><code class="code">services:
  mockServer:
    image: mockserver/mockserver
    ports:
      - "1080:1080"
    environment:
      JAVA_TOOL_OPTIONS: "-Xmx512m"
      MOCKSERVER_MAX_LOG_ENTRIES: "5000"</code></pre>

<p>When running as a standalone JAR:</p>
<pre class="code" style="padding: 2px;"><code class="code">java -Xmx512m -jar mockserver-netty.jar -serverPort 1080</code></pre>

<h3>Monitoring Memory Usage</h3>

<p>To diagnose memory issues, enable CSV memory tracking:</p>
<pre class="code" style="padding: 2px;"><code class="code">docker run -d --rm -p 1080:1080 \
  -e MOCKSERVER_OUTPUT_MEMORY_USAGE_CSV=true \
  -e MOCKSERVER_MEMORY_USAGE_CSV_DIRECTORY=/config \
  -v $(pwd):/config \
  mockserver/mockserver</code></pre>

<p>This creates a <span class="inline_code">memoryUsage_&lt;date&gt;.csv</span> file that records heap usage, log entry count, and expectation count over time. If you see heap usage consistently near the maximum, increase <span class="inline_code">-Xmx</span> or reduce <span class="inline_code">maxLogEntries</span>.</p>

<h2>Scalability Configuration:</h2>

<button id="button_configuration_nio_event_loop_thread_count" class="accordion title"><strong>Number of Event Loop Threads</strong></button>
<div class="panel title">
    <p>Number of threads for main event loop</p>
    <p>These threads are used for fast non-blocking activities such as:</p>
    <ul>
        <li>reading and de-serialise all requests</li>
        <li>serialising and writing control plane responses</li>
        <li>adding, updating or removing expectations</li>
        <li>verifying requests or request sequences</li>
        <li>retrieving logs</li>
    </ul>
    <p>Expectation actions are handled in a separate thread pool to ensure slow object or class callbacks and response / forward delays do not impact the main event loop.</p>
    <p>Type: <span class="keyword">int</span> Default: <span class="this_value">5</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.nioEventLoopThreadCount(int count)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.nioEventLoopThreadCount=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_NIO_EVENT_LOOP_THREAD_COUNT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.nioEventLoopThreadCount=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.nioEventLoopThreadCount="5"</code></pre>
</div>

<button id="button_configuration_action_handler_thread_count" class="accordion title"><strong>Number of Action Handler Threads</strong></button>
<div class="panel title">
    <p>Number of threads for the action handler thread pool</p>
    <p>These threads are used for handling actions such as:</p>
    <ul>
        <li>serialising and writing expectation or proxied responses</li>
        <li>handling response delays in a non-blocking way (i.e. using a scheduler)</li>
        <li>executing class callbacks</li>
        <li>handling method / closure callbacks (using web sockets)</li>
    </ul>
    <p>Type: <span class="keyword">int</span> Default: <span class="this_value">maximum of 5 or available processors count</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.actionHandlerThreadCount(int count)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.actionHandlerThreadCount=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_ACTION_HANDLER_THREAD_COUNT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.actionHandlerThreadCount=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.actionHandlerThreadCount="5"</code></pre>
</div>

<button id="button_configuration_client_nio_event_loop_thread_count" class="accordion title"><strong>Number of Client Event Loop Threads</strong></button>
<div class="panel title">
    <p>Number of threads for client event loop when calling downstream</p>
    <p>These threads are used for fast non-blocking activities such as, reading and de-serialise all requests and responses</p>
    <p>Type: <span class="keyword">int</span> Default: <span class="this_value">5</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.clientNioEventLoopThreadCount(int count)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.clientNioEventLoopThreadCount=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_CLIENT_NIO_EVENT_LOOP_THREAD_COUNT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.clientNioEventLoopThreadCount=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.clientNioEventLoopThreadCount="5"</code></pre>
</div>

<button id="button_configuration_web_socket_event_loop_thread_count" class="accordion title"><strong>Number of Client Web Socket Event Loop Threads</strong></button>
<div class="panel title">
    <p>Number of threads for each expectation with a method / closure callback (i.e. web socket client) in the <strong>org.mockserver.client.MockServerClient</strong></p>
    <p>This setting only effects the Java client and how requests each method / closure callbacks it can handle, the default is 5 which should be suitable except in extreme cases.</p>
    <p>Type: <span class="keyword">int</span> Default: <span class="this_value">5</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.webSocketClientEventLoopThreadCount(int count)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.webSocketClientEventLoopThreadCount=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_WEB_SOCKET_CLIENT_EVENT_LOOP_THREAD_COUNT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.webSocketClientEventLoopThreadCount=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.webSocketClientEventLoopThreadCount="5"</code></pre>
</div>

<button id="button_configuration_max_socket_timeout" class="accordion title"><strong>Maximum Future Timeout In Millis</strong></button>
<div class="panel title">
    <p>Maximum time allowed in milliseconds for any future to wait, for example when waiting for a response over a web socket callback.</p>
    <p>Type: <span class="keyword">long</span> Default: <span class="this_value">90000</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.maxFutureTimeout(long milliseconds)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.maxFutureTimeout=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_MAX_FUTURE_TIMEOUT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.maxFutureTimeout=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.maxFutureTimeout="90000"</code></pre>
</div>

<button id="button_configuration_matchers_fail_fast" class="accordion title"><strong>Request Matchers Fail Fast</strong></button>
<div class="panel title">
    <p>If true (the default) request matchers will fail on the first non-matching field, if false request matchers will compare all fields.</p>
    <p>Set to <code>false</code> when debugging matching issues to see all mismatching fields in a single log entry. See <a href="/mock_server/troubleshooting_matching.html">Troubleshooting Matching</a> for a step-by-step guide.</p>
    <p>Type: <span class="keyword">boolean</span> Default: <span class="this_value">true</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.matchersFailFast(boolean enable)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.matchersFailFast=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_MATCHERS_FAIL_FAST=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.matchersFailFast=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.matchersFailFast="false"</code></pre>
</div>

<button id="button_configuration_performance_log_level" class="accordion title"><strong>Log Level</strong></button>
<div class="panel title">
    <p>The the minimum level of logs to record in the event log and to output to system out (if <a href="#button_configuration_performance_disable_system_out">system out log output</a> is not disabled).  The lower the log level the more log entries will be captured, particularly at TRACE level logging.</p>
    <p>Type: <span class="keyword">string</span> Default: <span class="this_value">INFO</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.logLevel(String level)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.logLevel=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_LOG_LEVEL=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.logLevel=...</code></pre>
    <p>The log level, which can be TRACE, DEBUG, INFO, WARN, ERROR, OFF, FINEST, FINE, INFO, WARNING, SEVERE</p>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.logLevel="DEBUG"</code></pre>
</div>

<button id="button_configuration_performance_disable_system_out" class="accordion title"><strong>Disable Logging To System Out</strong></button>
<div class="panel title">
    <p>Disable logging to the system output</p>
    <p>Type: <span class="keyword">boolean</span> Default: <span class="this_value">false</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.disableSystemOut(boolean disableSystemOut)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.disableSystemOut=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_DISABLE_SYSTEM_OUT=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.disableSystemOut=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.disableSystemOut="true"</code></pre>
</div>

<button id="button_configuration_performance_disable_logging" class="accordion title"><strong>Disable Logging To System Out</strong></button>
<div class="panel title">
    <p>Disable logging output to system out. Request/response log entries are still recorded in memory for verification.</p>
    <p>Type: <span class="keyword">boolean</span> Default: <span class="this_value">false</span></p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.disableLogging(boolean disableLogging)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.disableLogging=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_DISABLE_LOGGING=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.disableLogging=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.disableLogging="true"</code></pre>
</div>

<button id="button_configuration_max_llm_conversation_body_size" class="accordion title"><strong>Maximum LLM Conversation Body Size</strong></button>
<div class="panel title">
    <p>Maximum request body size in bytes that conversation-aware LLM matchers will parse. LLM conversation matchers (<span class="inline_code">whenLatestMessageContains</span>, <span class="inline_code">whenContainsToolResultFor</span>, etc.) parse the inbound request body as JSON to extract the message history. For deep conversation histories or large tool results, this parse step is proportional to body size.</p>
    <p>Requests whose body exceeds this cap skip conversation-aware matching and are treated as a no-match for conversation predicates (the scenario state machine is unaffected). Increase this value only when your LLM conversations regularly include very large tool results or long message histories. Reduce it in memory-constrained environments to bound the maximum allocation per matching attempt.</p>
    <p>Type: <span class="keyword">int</span> Default: <span class="this_value">1048576</span> (1 MiB) Range: <span class="this_value">16384</span> (16 KiB) &mdash; <span class="this_value">67108864</span> (64 MiB)</p>
    <p>Java Code:</p>
    <pre class="prettyprint lang-java code"><code class="code">ConfigurationProperties.maxLlmConversationBodySize(int size)</code></pre>
    <pre class="prettyprint lang-java code"><code class="code">Configuration.maxLlmConversationBodySize(Integer size)</code></pre>
    <p>System Property:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.maxLlmConversationBodySize=...</code></pre>
    <p>Environment Variable:</p>
    <pre class="code" style="padding: 2px;"><code class="code">MOCKSERVER_MAX_LLM_CONVERSATION_BODY_SIZE=...</code></pre>
    <p>Property File:</p>
    <pre class="code" style="padding: 2px;"><code class="code">mockserver.maxLlmConversationBodySize=...</code></pre>
    <p>Example:</p>
    <pre class="code" style="padding: 2px;"><code class="code">-Dmockserver.maxLlmConversationBodySize="4194304"</code></pre>
</div>