Dynamic request data keeps a JMeter test plan from replaying the same IDs, timestamps, and environment names on every sampler. Functions such as __time, __Random, __counter, and __P resolve while the test runs, so a static HTTP Request field can produce values that differ by sample or by run.

The Function Helper Dialog under Tools builds the function call and fills in required arguments, which reduces syntax mistakes when a field contains several parameters. The generated string is ordinary test-plan text, so it can be pasted into sampler parameters, headers, assertions, or pre/post-processors that evaluate during the run.

Changing functions belong in runtime fields rather than User Defined Variables rows, because UDV elements are processed at startup and keep only the first generated value. Property functions such as __P are appropriate when one run should keep a fixed environment, hostname, or count supplied from the command line.

Steps to use JMeter functions for dynamic request values:

  1. Open the test plan in the JMeter GUI.
  2. Select the sampler, header, assertion, or processor field that needs a runtime value.
  3. Open ToolsFunction Helper Dialog.
  4. Generate the function call for each changing value.

    The helper shows the required arguments and copies the generated string. When typing a date format manually, escape commas as \, so JMeter does not split one format into multiple function arguments.

  5. Paste the function strings into the sampler fields.
    orderId=${__time(/1000,epoch_seconds)}-${__Random(100000,999999,random_part)}
    sequence=${__counter(TRUE,order_seq)}
    env=${__P(target.env,dev)}

    __time stores the epoch-second prefix in epoch_seconds, __Random stores the random suffix in random_part, __counter(TRUE,order_seq) keeps a per-user sequence, and __P(target.env,dev) reads the command-line property or falls back to dev.

  6. Reuse stored function variables only after their function has run.
    request_id=${epoch_seconds}-${random_part}
    request_sequence=${order_seq}

    A variable name passed as the last function argument captures the value generated by that call. Use it later in the same thread scope when another field needs the exact same value.

  7. Keep changing functions out of User Defined Variables rows.

    JMeter processes UDV elements at startup. A random, counter, or time function there saves only its first generated value instead of changing per sample.

  8. Add temporary result visibility for a short validation run.

    Use a Debug Sampler or View Results Tree while developing in the GUI, or add sample_variables=epoch_seconds,random_part,order_seq for a CLI validation run. Remove heavy debug listeners before a load run.
    Related: How to add a Debug Sampler in JMeter
    Related: How to disable heavy JMeter listeners before a load test

  9. Save the validation plan as dynamic-values.jmx.
  10. Run one thread and a few loops against a non-production endpoint that can receive throwaway checkout requests.
    $ jmeter -n -t dynamic-values.jmx -Jtarget.env=staging -Jsample_variables=epoch_seconds,random_part,order_seq -l dynamic-values.jtl
    Creating summariser <summary>
    Created the tree successfully using dynamic-values.jmx
    Starting standalone test @ 2026 Jun 29 23:10:12 GMT
    Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 4445
    summary =      3 in 00:00:00 =   32.6/s Avg:     6 Min:     1 Max:    16 Err:     0 (0.00%)
    Tidying up ...
    ... end of run

    -Jtarget.env=staging supplies the property read by __P. The sample_variables property is only for the debug run so the generated variables are written to the result file.
    Related: How to run a JMeter test from the command line

  11. Check the receiving application log or local request log for resolved request values.
    $ cat request.log
    GET /checkout?orderId=1782774612-850228&sequence=1&env=staging HTTP/1.1
    GET /checkout?orderId=1782774612-312183&sequence=2&env=staging HTTP/1.1
    GET /checkout?orderId=1782774612-487086&sequence=3&env=staging HTTP/1.1

    The timestamp prefix can repeat when samples run inside the same second. The random suffix and sequence values should still change according to the selected functions.

  12. Inspect the result file when receiver logs are not available.
    $ cat dynamic-values.jtl
    timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect,"epoch_seconds","random_part","order_seq"
    1782774612411,16,checkout dynamic request,200,OK,Checkout users 1-1,text,true,,85,174,1,1,http://127.0.0.1:8080/checkout?orderId=1782774612-850228&sequence=1&env=staging,13,0,11,1782774612,850228,1
    1782774612427,1,checkout dynamic request,200,OK,Checkout users 1-1,text,true,,85,174,1,1,http://127.0.0.1:8080/checkout?orderId=1782774612-312183&sequence=2&env=staging,1,0,0,1782774612,312183,2
    1782774612428,1,checkout dynamic request,200,OK,Checkout users 1-1,text,true,,85,174,1,1,http://127.0.0.1:8080/checkout?orderId=1782774612-487086&sequence=3&env=staging,1,0,0,1782774612,487086,3
  13. Remove temporary debug visibility before the load run.

    Delete temporary Debug Sampler and View Results Tree elements, and drop the sample_variables property unless the run is still a controlled validation run.