You inherit a JMeter plan whose BeanShell elements cap the injector. How do you plan the move off them?

## First, separate the three populations An inherited plan's scripted elements are almost never one problem. Before choosing a target, sort them, because the cheapest win is usually not a rewrite: 1. **Scripts that duplicate a stock element.** A BeanShell PostProcessor pulling one value out of a body, a BeanShell Timer returning a constant, a BeanShell Assertion checking a substring. Each of these has a built-in equivalent — a Regular Expression Extractor or JSON Extractor, a Constant Timer, a Response Assertion — that costs no interpretation at all. 2. **Scripts that exist only for logging or debugging.** Left over from an incident three years ago, running on every sample of every thread. 3. **Scripts that genuinely encode behaviour** the plan cannot express otherwise: signing a payload, deriving a token, building a body from several captured values. Only the third population is a migration. The first is a **replacement** and the second is a **deletion**, and both remove the cost entirely rather than reducing it. ## Then rank by executions, not by line count The cost of a BeanShell element is per invocation, so the ranking that matters is how often it runs, not how long the script looks. Two elements deserve a hard look first: - Anything scoped so that it applies to a whole Thread Group, which means it runs for every sampler under it rather than for the one request you were thinking about. - Anything on the busiest request in the plan. Be careful about how you attribute the slowdown in the first place. Only a BeanShell **Sampler** records its own interpretation time as a sample; a PreProcessor, PostProcessor, Assertion, Listener or Timer spends injector CPU that no row in the results file accounts for. Whether the injector, as opposed to the system under test, is the constraint at all is a performance-run methodology question, not a JMeter one — settle it before you plan work on the strength of it. ## What the migration itself will cost you State the risks up front, because they are what make this a judgement call rather than a chore: | Risk | Why it bites | |---|---| | Behaviour drift | A rewritten script that is subtly different silently changes what the run measures | | Review capacity | A `.jmx` diff of many changed script fields is close to unreviewable | | Loss of continuity | The converted plan is a different plan; the first run after it is a new reference, not a comparison | | Sunk knowledge | The person who wrote the script has usually left; the script is the only surviving spec | ## A defensible sequence 1. Delete the dead and the merely chatty scripts. No behaviour change to argue about. 2. Replace the duplicates with stock elements, one element per change, re-running the plan each time so a behaviour difference is attributable. 3. Convert what remains, in descending order of executions per run. 4. Re-baseline once, deliberately, at the end — not silently, element by element. ## When the right answer is "not yet" Leave it alone if the plan is scheduled for retirement, if it runs at a load its current injector handles comfortably, or if the scripted elements sit on paths that execute once per thread rather than once per sample. A plan that is not the constraint does not become one because it uses a legacy element family, and Apache JMeter 6.0.0 still ships and runs that family. The engineering question is what the injector's headroom is worth against the review cost of touching a plan nobody fully understands — and that trade is yours to state explicitly, with a number, rather than to resolve by preference for the newer element.