Jmeter Webdriver sampler -

jmeter has webdriver sampler. have write scripts. have scripts written in opkey, selenium based tool. can integrate both of them. don't have write scripts in jmeter.

not familiar opkey, selenium bad idea load tests beyond trivial loads:

selenium never intended large-scale performance testing. selenium , newer avatar webdriver, launch browser engine per user , replay user interactions inside it. great functional testing because executing client side code inside real browser engine - @ same time bad news performance testing. browser instances resource intensive, , scaling becomes hard , expensive.

even using selenium grid meant cutting test execution time running in parallel, not generating sort of loads. @ top of their faq.

it not scale, when load driver resource intensive, applied load becomes inconsistent. if see drop in performance, load driver bottleneck , not application under test.

having said that, can use jmeter sampler, or se grid, or else drive performance test, long you're in scale of 10s of parallel users. again quoting grid faq:

to simulate 200 concurrent users instance, need 200 concurrent browsers load testing framework based on selenium grid. if use firefox on linux (so efficient setup) need @ least 10 machines generate kind of load. quite insane when jmeter/grinder/httperf can generate same kind of load single machine.

note when jmeter, referring http sampler or 1 of simpler, more efficient samplers - because webdriver sampler documentation says this:

jmeter allows creation of multiple threads, , each thread responsible creating load on server. however, web driver use case, reader should prudent in number of threads create each thread have single browser instance associated it. each browser consumes significant amount of resources, , limit should placed on how many browsers reader should create.

and goes on recommend using maximum of (1 less #of processor cores) - small number non-elastic setups.