Private corporate batches, live online cohorts and 1-on-1 mentoring in load, stress and soak testing of APIs, web applications and back-end services with Apache JMeter — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches JMeter around measurement validity rather than button order — why a recorded script fails without correlation, why assertions are the difference between measuring success and measuring fast error pages, and why percentiles rather than averages are what a performance requirement should be written against. Sessions build plans element by element with the execution order made explicit, cover correlation and parameterisation with extractors and CSV data sets, then move to realistic load modelling with pacing and arrival-rate thread groups, non-GUI execution and distributed testing across remote engines. The course closes on analysis and continuous performance testing: the JTL and HTML dashboard, backend listeners streaming to a time-series store, baselines, and pipeline thresholds that fail a build on regression.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For JMeter that means a trainer who has run it in production — load, stress and soak testing of APIs, web applications and back-end services with Apache JMeter — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private JMeter batchJMeter is an open-source, Java-based load and performance testing tool from the Apache Software Foundation. It generates concurrent traffic against a system, measures how that system responds, and reports the result — response times, throughput, error rates and their distribution under load. It began as an HTTP tool and now drives REST and SOAP APIs, databases over JDBC, message queues over JMS, FTP, mail protocols, TCP and, through plugins, gRPC and WebSocket endpoints.
A JMeter test is a tree. A thread group defines the virtual users and how they arrive; samplers issue the actual requests; logic controllers shape the flow; config elements supply defaults, headers, cookies and data; timers create think time; assertions decide whether a response was correct rather than merely returned; and pre- and post-processors extract and inject the dynamic values that make a recorded script work for more than one user. Understanding the execution order of those elements is most of what separates a test that measures something from a test that produces plausible-looking numbers.
In practice JMeter is used non-graphically. The GUI is for building and debugging a plan; a real run happens headless on a load generator, writing a JTL results file that becomes an HTML dashboard, with a backend listener streaming live metrics to a time-series store for graphing. When one machine is no longer enough, JMeter runs distributed with a controller driving remote engines. That combination — free, scriptable, protocol-broad and CI-friendly — is why it remains the default performance tool in a large share of engineering organisations.
Performance problems have become expensive in a way they were not when applications were monoliths on known hardware. Microservices, third-party APIs, autoscaling and pay-per-use infrastructure mean a load profile now determines both user experience and monthly cost, and the failure modes are emergent — a service that is fine at 200 users falls over at 400 because a connection pool, not a CPU, ran out.
Most organisations do have a JMeter script somewhere. What they usually lack is anyone who can say whether it means anything. Tests are commonly built by recording a browser session and replaying it without correlating session tokens, so every virtual user hits an error page fast and the report shows excellent response times for failure. Load is modelled as a flat thread count with no pacing, which resembles no real traffic pattern. Results are read as averages, which hide exactly the tail latency users complain about. Each of these is fixable, and fixing them is the skill being hired for.
The third driver is continuous performance testing. A load test run once before release finds problems when they are most expensive to fix. A smaller test run on every build, with thresholds that fail the pipeline on regression and metrics streamed to a dashboard, catches them while the change is still fresh — and that is what teams increasingly ask a trainer to help them build.
The discipline before the tool. What each test type actually answers, how to turn a vague performance expectation into a measurable requirement, and the metrics that matter — throughput, concurrency, response time distribution and error rate. Then JMeter's architecture and an honest comparison with the alternatives.
Topics: Load, stress, soak, spike and capacity testing and what each answers · Turning expectations into measurable non-functional requirements · Throughput, concurrency, latency and error rate · Why percentiles matter and averages mislead · JMeter architecture and its Java foundation · GUI mode for building, non-GUI mode for running · JMeter compared with Gatling, k6 and Locust · Where JMeter is the wrong tool
Setting up JMeter properly, then the structure of a test plan. Every element category, what each is for, and — the part most courses skip — the order in which JMeter executes them, because a config element placed in the wrong scope silently changes what the whole plan measures.
Topics: Installing JMeter and configuring the JVM and heap · The Plugins Manager and useful plugin sets · Test plan structure and the element tree · Thread groups and virtual user definition · Samplers, logic controllers and their scope · Config elements, timers, assertions, pre- and post-processors · Listeners and their cost during a real run · Element execution order and scoping rules · Saving, organising and version-controlling test plans
The core work. HTTP request samplers and the defaults, header, cookie and cache managers that make them behave like a browser. Recording with the test script recorder and — critically — cleaning up what it produces, because a raw recording is never a working test.
Topics: HTTP request samplers and request configuration · HTTP Request Defaults and shared configuration · Header Manager, Cookie Manager and Cache Manager · The HTTP(S) Test Script Recorder and browser proxy setup · Cleaning a recording: static resources, third-party calls, noise · REST API testing: JSON bodies, auth headers, tokens · SOAP requests and XML payloads · Handling redirects, embedded resources and connection reuse
The module that decides whether the numbers mean anything. Extracting dynamic values so each virtual user has its own session, feeding distinct data to each user, and asserting on the response so a fast error page is recorded as a failure instead of excellent performance.
Topics: Why a replayed recording fails at scale: the correlation problem · Regular Expression Extractor · JSON Extractor and JSONPath · Boundary Extractor and XPath Extractor · JMeter variables versus properties · CSV Data Set Config and per-user data · JMeter functions: counter, threadNum, time, random, V and eval · Response, duration, size and JSON assertions · Debugging with the Debug Sampler and View Results Tree
Testing the parts of a system that are not a web front end. JDBC for database load, JMS for messaging, FTP and mail samplers, plugin-provided WebSocket and gRPC support — and JSR223 scripting with Groovy for the logic no built-in element expresses.
Topics: JDBC connection configuration and JDBC request samplers · Database load testing and connection pool behaviour · JMS point-to-point and publish/subscribe testing · FTP, SMTP and TCP samplers · WebSocket and gRPC testing via plugins · JSR223 samplers, pre- and post-processors with Groovy · Why Groovy rather than legacy scripting languages · Reusable script snippets and shared functions · Custom logic without hurting load generator performance
Making the generated traffic resemble the real thing, and generating enough of it. Ramp profiles, think time and pacing, arrival-rate and concurrency thread groups from the plugin set, then non-GUI execution and distributed testing with a controller and remote engines — plus recognising when the load generator, not the system, is the bottleneck.
Topics: Ramp-up, steady state and ramp-down profiles · Think time and pacing with timers · Constant Throughput Timer and throughput shaping · Concurrency and arrival-rate thread groups from the plugin set · Running JMeter non-GUI from the command line · Command-line properties and parameterising a run · Distributed testing: controller and remote engines · Load generator sizing, JVM tuning and OS limits · Detecting when the generator is the bottleneck
Turning a results file into a decision, then into a control. Reading the JTL and the HTML dashboard by percentile rather than average, streaming live metrics to a time-series store for graphing, establishing baselines, and wiring a smaller test into CI with thresholds that fail a build on regression.
Topics: The JTL results file and what to save in it · Generating and reading the HTML dashboard report · Percentiles, response time distribution and outliers · Correlating load test results with server-side and APM metrics · Backend Listener streaming to InfluxDB and graphing in Grafana · Establishing and maintaining a performance baseline · Running JMeter from a CI pipeline · Thresholds and failing a build on regression · Reporting findings to engineering and to management
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a plan containing every element category, predict the execution order and the resulting request sequence, then run it and reconcile the difference.
Take a recorded login journey that passes at one user and fails silently at fifty, correlate the session values, and add assertions that expose the original failures.
Drive a test with a CSV data set so every virtual user has distinct credentials and payload, and handle data exhaustion and recycling deliberately.
Replace a flat thread count with an arrival-rate model, pacing and think time that reproduces a real daily pattern, and compare the results against the naive version.
Run a non-GUI distributed test across a controller and two engines, monitor the generators themselves, and prove the bottleneck is the system under test.
Baseline a test, stream metrics to a time-series dashboard, run a reduced version in CI, and fail the pipeline on a real latency regression.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.