How to Add Branch Logic and Synchronize Endpoints in Chain Performance Testing

Background

Previous articles on chain load testing covered single‑link testing and parameter flow, yielding decent results. However, real‑world testing often encounters data preparation errors, environment changes, and data staleness, making it impossible to guarantee that every link follows the designed number of executions and paths.

No‑Branch Chain Testing Issues

Data errors can cause the chain implementation to throw exceptions, which are caught in the doing() method. While a single request failure may have limited impact, it can significantly affect subsequent chain executions. For example, if a previous test fails to cancel a bookmarked course, the next run may receive fewer push recommendations, exhausting test data and causing the entire test to fail.

Another scenario is when a failed chain combined with per‑thread user binding leads to cascading failures, as described in articles about password‑change and create‑delete interface load testing, potentially doubling the error rate and skewing statistics.

Introducing Branch Logic into the Chain

To mitigate these problems, I added simple logical checks before or after each chain node to divert execution paths. For instance, if the list of knowledge points is empty, the thread ends early, reducing the overall thread count and rendering further testing meaningless, so the entire performance test should stop.

The same logical control can adjust request ratios for different interfaces, differing from the static HttpRequestBase objects generated in multi‑threaded tasks. By inserting a logical controller, the number of requests or their order can be statically or dynamically tuned.

Below are two concrete modifications applied to the single‑link performance test case:

@Override
public void run() {
    try {
        before();
        long ss = Time.getTimeStamp();
        while (true) {
            try {
                threadmark = mark == null ? EMPTY : this.mark.mark(this);
                long s = Time.getTimeStamp();
                doing();
                long et = Time.getTimeStamp();
                executeNum++;
                int diff = (int) (et - s);
                costs.add(diff);
                if (diff > HttpClientConstant.MAX_ACCEPT_TIME)
                    marks.add(diff + CONNECTOR + threadmark + CONNECTOR + Time.getNow());
                if ((et - ss) > time || status() || ThreadBase.needAbort()) break;
            } catch (Exception e) {
                logger.warn("Execution task failed!", e);
                logger.warn("Failed object mark:{}", threadmark);
                errorNum++;
            }
            long ee = Time.getTimeStamp();
            logger.info("Thread:{}, executions:{}, failures:{}, total time:{} s", threadName, executeNum, errorNum, (ee - ss) / 1000.0);
            Concurrent.allTimes.addAll(costs);
            Concurrent.requestMark.addAll(marks);
        }
    } catch (Exception e) {
        logger.warn("Execution task failed!", e);
    } finally {
        after();
    }
}

Key branch controllers added:

If the knowledge‑point list size is less than 3, terminate the thread: if (karray.size() < 3) return ThreadBase.stop(); If the recommendation list length is less than 2, skip the current chain execution without affecting subsequent runs:

if (karray.size() < 2) return;

Synchronous Test Termination

When branches exist, execution times vary across threads. Waiting for all threads to finish before aggregating results increases error. Therefore, the test should stop as soon as the fastest thread completes.

@Override
protected void after() {
    super.after();
    ThreadBase.stop();
}

By overriding after() to call stop(), the first thread that finishes triggers an immediate shutdown of all remaining threads, ensuring consistent data collection.